Date: Sat, 3 Aug 2013 00:25:48 +0400 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: freebsd-arch@freebsd.org Subject: Re: [PROPOSAL] GEOM probing/tasting firewall Message-ID: <20130802202548.GA57445@zxy.spb.ru> In-Reply-To: <20130802190431.GH5771@garage.freebsd.pl> References: <447183917.20130731130956@serebryakov.spb.ru> <51F91FAC.60905@freebsd.org> <20130802190431.GH5771@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 02, 2013 at 09:04:32PM +0200, Pawel Jakub Dawidek wrote: > 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 problems > > > with tasting these ZVOLs, which contain different types of data (Windows > > > disks, Linux disks, FreeBSD disks, etc). Here are label conflicts, strange > > > messages about corrupted GPTs, etc. So, it looks like to have configurable > > > way to prevent some GEOM tasting is good idea. > > > > I'm all for this. bhyve has the exact same problem with unnecessary > > 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/. In this case this is don't allowed export such zvol over iSCSI or in the hypervisor. > 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. Massive ZVOL snapshots is other case (and this case don't resolved by firewall). > 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/. And I don't allowed to see by `ls` list of created ZVOL? Bad.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130802202548.GA57445>