From owner-freebsd-current@FreeBSD.ORG Wed Oct 5 09:19:08 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FF21106564A; Wed, 5 Oct 2011 09:19:08 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6DD8FC19; Wed, 5 Oct 2011 09:19:07 +0000 (UTC) Received: by eyg7 with SMTP id 7so1905908eyg.13 for ; Wed, 05 Oct 2011 02:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=deYHTQDk1XjVSDTxGcSBLsGaFmMzgNJzJ2zt19TbIKQ=; b=XEQpabn8iW9nYSIURndiRu0CaO7clsKAlGKR6MoPFRdzHjDu1dRioGc0wpZfDijLzP 95uRtk5FrJkZKw/zGoKt1oJk9mvacacFhj5GCBYig/H7ZmomxhcxRahTekB1yeIgKB0c F6wMU6WIj7083eP6HnDDSHcvjIVQoUzhFzPlw= Received: by 10.223.47.207 with SMTP id o15mr3254687faf.88.1317806346376; Wed, 05 Oct 2011 02:19:06 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua. [212.86.226.226]) by mx.google.com with ESMTPS id a1sm1534102fab.4.2011.10.05.02.19.04 (version=SSLv3 cipher=OTHER); Wed, 05 Oct 2011 02:19:04 -0700 (PDT) Sender: Alexander Motin Message-ID: <4E8C20EA.5060501@FreeBSD.org> Date: Wed, 05 Oct 2011 12:18:34 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110910 Thunderbird/6.0.2 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz> <251861322.20111005125825@serebryakov.spb.ru> In-Reply-To: <251861322.20111005125825@serebryakov.spb.ru> X-Enigmail-Version: undefined Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-geom@FreeBSD.org, Miroslav Lachman <000.fbsd@quip.cz>, current@freebsd.org Subject: Re: RFC: Project geom-events X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 09:19:08 -0000 On 05.10.2011 11:58, Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 октября 2011 г., 12:24:06: > >>> What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? >>> Something else? >> I am mostly using geom_mirror. > [SKIPPED] > Oh, I see. Unfortunately, there is no GEOM metadata infrastructire, > GEOMs are too generic for this. I could design some meta-meta > framework, and unify all RAID classes with "intenral" metadtata > (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external > geom_raid5) to use it. In such case it will work -- kernel will not > pass providers with "ditry" metadtata to any GEOMs, but owners, for > tasting. Of course, classes like geom_part and geom_raid could not be > changed in such way -- they are forced to use pre-defined metadata > formats. geom_raid addresses this problem in own way. As soon as RAID BIOSes expect RAIDs to be built on raw physical devices and probe order is not discussed, geom_raid exclusively opens underlying providers immediately after detecting supported metadata. So even if volume is broken or incomplete or this disk marked failed, or in any other case, this disk won't be accessible for other GEOM classes. If administrator wishes to reuse this disk for any other purpose, he should explicitly erase on-disk metadata using graid tool or with dd after unloading geom_raid. Up to the recent time geom tools didn't report geoms without providers. Now there is special "-a" argument to report all of them. Also there is "-g" to report geoms instead of providers, that is useful in such cases. > It is good idea, but it should be separate project. And, yes, it > will change metadata format for these GEOMs, so it will not be > backward-compatible. > > And, yes, it seems to be much more intrusive change in GEOM > subsystem (because it will change tasting sequence), and should be > supervised by other developers from very beginning. > > I could write proposal in near future, with some design notes. -- Alexander Motin