Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

[Poul-Henning Kamp]

In message <20040114215347.P608 at korben.in.tern>, Lukas Ertl writes:
>On Mon, 12 Jan 2004, Robert Watson wrote:
>
>> I think the right strategy is to follow the minimalist approach now
>> (adopt the disk(9) API, rather than having Vinum generate character
>> devices) so that swap works on Vinum again, and so that when UFS moves
>> to speaking GEOM there's no loss of functionality.  If we want to
>> completely reimplement Vinum, we should do that separately so as to
>> avoid loss of functionality during structural changes.
>
>As many ways lead to Rome, how about the following scenario.  I don't know
>if it's a clever way to do things, and I don't know if it's even possible
>to with GEOM, so some input is appreciated.
>
>*) Have separate GEOM classes for each of the different vinum objects
>   (drive, sd, plex, volume).
>*) Let the drive geom taste the slices configured for vinum, read the
>   on-disk config and then spawn the necessary other geoms (I'm not sure
>   if the latter can be done in GEOM).
>*) I think this is a clean implementation, since the GEOM framework offers
>   all the "background" needed to transform the IO requests.
>*) It would also be a good way to clean up the vinum code.

It is possible in GEOM, but I am not convinced that fragmenting into
this many GEOM classes can be classified as an easy path to go.

I think for now the important thing is to get the people interested
on this collected on a mail-alias, and for them to discuss how the
can work together to make something happen.  After that, try to define
"something" closer.


-- 
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.