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

[Lukas Ertl]

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.

regards,
le

-- 
Lukas Ertl                             eMail: l.ertl at univie.ac.at
UNIX Systemadministrator               Tel.:  (+43 1) 4277-14073
Vienna University Computer Center      Fax.:  (+43 1) 4277-9140
University of Vienna                   http://mailbox.univie.ac.at/~le/