From owner-freebsd-geom@FreeBSD.ORG Fri Aug 2 19:57:31 2013 Return-Path: Delivered-To: freebsd-geom@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 90FE368B; Fri, 2 Aug 2013 19:57:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 533B82885; Fri, 2 Aug 2013 19:57:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:2418:88c5:96ef:35b4]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EEB374AC57; Fri, 2 Aug 2013 23:57:27 +0400 (MSK) Date: Fri, 2 Aug 2013 23:57:20 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <1472113917.20130802235720@serebryakov.spb.ru> To: Pawel Jakub Dawidek Subject: Re: [PROPOSAL] GEOM probing/tasting firewall In-Reply-To: <20130802190431.GH5771@garage.freebsd.pl> References: <447183917.20130731130956@serebryakov.spb.ru> <51F91FAC.60905@freebsd.org> <20130802190431.GH5771@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-geom@freebsd.org, Peter Grehan , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 19:57:31 -0000 Hello, Pawel. You wrote 2 =D0=B0=D0=B2=D0=B3=D1=83=D1=81=D1=82=D0=B0 2013 =D0=B3., 23:04:= 32: PJD> Firewall idea is overkill for my taste. I'd much prefer to have a flag PJD> which would tell GEOM not to present GEOM provider I'm creating for PJD> tasting. This also means it would not be available via /dev/. I've thought about cases like "GPT in gmirror" and, worse, "MBR in gmirror" to solve by such "overkill" solution -- you don't allow geom_label to taste devices, which are included in mirror (or other RAID), but allow to taste them by anything else, so they have /dev entries and picked up by soft-RAID class they belong to... There was MANY threads about such problems in the past, and I don';t remember to have good solution but "make mirrors out of partitions". Several solutions were discussed, like "levels" of classes (to make tasting order predicatable), but, as far as I understand, nothing was done, and no good solution was found. --=20 // Black Lion AKA Lev Serebryakov