Date: Wed, 5 Oct 2011 12:58:25 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Miroslav Lachman <000.fbsd@quip.cz> Cc: Alexander Motin <mav@FreeBSD.org>, current@freebsd.org, freebsd-geom@FreeBSD.org Subject: Re: RFC: Project geom-events Message-ID: <251861322.20111005125825@serebryakov.spb.ru> In-Reply-To: <4E8C1426.60107@quip.cz> References: <1927112464.20111004220507@serebryakov.spb.ru> <4E8B7A27.5070908@quip.cz> <344794801.20111005101957@serebryakov.spb.ru> <4E8C1426.60107@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Miroslav. You wrote 5 =EE=EA=F2=FF=E1=F0=FF 2011 =E3., 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. 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. --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?251861322.20111005125825>