From owner-freebsd-arch@FreeBSD.ORG Fri Aug 2 19:04:05 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 90A0958F; Fri, 2 Aug 2013 19:04:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 5698B2614; Fri, 2 Aug 2013 19:04:05 +0000 (UTC) Received: from localhost (host-188-252-7-16.idev.pl [188.252.7.16]) by mail.dawidek.net (Postfix) with ESMTPSA id E63E5B37; Fri, 2 Aug 2013 20:58:54 +0200 (CEST) Date: Fri, 2 Aug 2013 21:04:32 +0200 From: Pawel Jakub Dawidek To: Peter Grehan Subject: Re: [PROPOSAL] GEOM probing/tasting firewall Message-ID: <20130802190431.GH5771@garage.freebsd.pl> References: <447183917.20130731130956@serebryakov.spb.ru> <51F91FAC.60905@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7J16OGEJ/mt06A90" Content-Disposition: inline In-Reply-To: <51F91FAC.60905@freebsd.org> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-geom@freebsd.org, lev@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 19:04:05 -0000 --7J16OGEJ/mt06A90 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 31, 2013 at 07:31:08AM -0700, Peter Grehan wrote: > > For first time this idea was formulated in Jabber talk with friend of > > mine, who uses FreeBSD for massive iSCSI hosting on ZVOLs. He has pro= blems > > with tasting these ZVOLs, which contain different types of data (Wind= ows > > disks, Linux disks, FreeBSD disks, etc). Here are label conflicts, st= range > > messages about corrupted GPTs, etc. So, it looks like to have configu= rable > > way to prevent some GEOM tasting is good idea. >=20 > I'm all for this. bhyve has the exact same problem with unnecessary=20 > tasting of zvols and raw volumes being used by guest o/s's. Firewall idea is overkill for my taste. I'd much prefer to have a flag which would tell GEOM not to present GEOM provider I'm creating for tasting. This also means it would not be available via /dev/. We would still need a way to selectively make those providers available via /dev/ or just presented for tasting, but ZVOL snapshots seems to be good candidates for such a flag. For regular ZFS file systems there is 'canmount' property which controls if the given file system should be mounted automatically or not. Maybe we need similar property for ZVOL snapshots that would enable/disable GEOM tasting. Another idea is to implement lazy device creation in /dev/ - when provider is created with this don't-taste flag its corresponding /dev/ entry is not created, because the DEV GEOM class didn't taste it. But DEV class could respond to devfs lookups by trying to find provider by name (there is function for that already) and when found, create /dev/ entry for it. This would make providers that don't like to be tasted still available through /dev/. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --7J16OGEJ/mt06A90 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlH8Ar8ACgkQForvXbEpPzRQvwCeKciHHr6IeDDuFPy9L8LtWlnk regAoJSmkPC8+IwR5jhBnMMlEkg3Pm6d =E1cC -----END PGP SIGNATURE----- --7J16OGEJ/mt06A90--