On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, 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 it's probably a good ultimate aim, but I don't think it should be the first step. > 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. A mailing lists exists. [EMAIL PROTECTED] If somebody wants to put in a FreeBSD version, that wouldn't be a disadvantage. Greg -- See complete headers for address and phone numbers.
pgp00000.pgp
Description: PGP signature
