geom_mirror implementation

[Poul-Henning Kamp]

In message <20031109023041.GA9171 at VARK.homeunix.com>, David Schultz writes:
>On Sun, Nov 09, 2003, Lukas Ertl wrote:
>> Hi hackers@,
>> 
>> I've played around with GEOM a bit and beefed up geom_mirror, which is
>> already in the tree but not built yet.
>> 
>> You can find the patch at <http://mailbox.univie.ac.at/~le/geom.diff>.
>
>Hmm...I believe geom_mirror is supposed to be an example, and
>geom_ccd is supposed to be the production mirroring implementation.  
>ccd does have its quirks, though...

I guess I should just weigh in here:

geom_mirror was meant mostly as a "hands on" example to inspire
people writing GEOM classes.  It is 100% inside the envelope to
improve geom_mirror and provided the patches are sane I see no reason
not to commit them.

GEOM_CCD has many shortcomings and is only provided for backwards
compatibility.  It should die, rather than be improved.

In general my position is that I would like to get a chance to see
any patch committed to the GEOM infrastructure before it's committed
(unless it is just trivial matters like typos etc:  just go ahead).

For individual GEOM classes I'll be happy to review and comment
(time permitting) and generally don't care what people do as long
as they don't break my system.


With regards to the larger "volume management picture" I will
reiterate my position:

Ideally I would prefer to have a set of primitive GEOM classes,
GEOM_MIRROR, GEOM_STRIPE, GEOM_RAID5 etc and a separate set of
"controller" GEOM classes, GEOM_VINUM, GEOM_RF, GEOM_VERITAS, to
recognize the various "traditional LVM" metadata on the disk, and
from that metadata stack the primitive modules.  This would in the
long term give us the maximal flexibility and ability with the
least code.

But since I am not going to do that (lack of time), I will not try
to impose my will on the people who are doing the work:  GEOM is
extensible enough for us to have any number of (competing) classes.

So realistically I expect that we will some day soon see a
GEOM_RAIDFRAME (I gather Pawel is trying to help Scott on this).
Maybe we will also see a GEOM_VINUM class and who knows what else.

And maybe some day down the road, somebody will pick up on the
consolidation idea, or maybe he will instead show it to be hopelessly
idealistic and burried it firmly.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.