From owner-freebsd-arch@FreeBSD.ORG Fri Aug 2 20:24:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C054AA97 for ; Fri, 2 Aug 2013 20:24:57 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7A072298C for ; Fri, 2 Aug 2013 20:24:57 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1V5Lv2-000EzX-2W for freebsd-arch@freebsd.org; Sat, 03 Aug 2013 00:25:48 +0400 Date: Sat, 3 Aug 2013 00:25:48 +0400 From: Slawa Olhovchenkov To: freebsd-arch@freebsd.org Subject: Re: [PROPOSAL] GEOM probing/tasting firewall Message-ID: <20130802202548.GA57445@zxy.spb.ru> References: <447183917.20130731130956@serebryakov.spb.ru> <51F91FAC.60905@freebsd.org> <20130802190431.GH5771@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130802190431.GH5771@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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 20:24:57 -0000 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.