Date: Thu, 15 Jan 2004 08:56:16 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: Robert Watson <rwatson@freebsd.org> Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) Message-ID: <20040114222616.GC64370@wantadilla.lemis.com> In-Reply-To: <29577.1074115952@critter.freebsd.dk> References: <20040114215347.P608@korben.in.tern> <29577.1074115952@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote: > In message <20040114215347.P608@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 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. vinum-devel@auug.org.au. If somebody wants to put in a FreeBSD version, that wouldn't be a disadvantage. Greg -- See complete headers for address and phone numbers. --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQFABcIIIubykFB6QiMRAhY5AJ9tk0gu0ZojXiZ1J70cwZ6Tf97u/wCeLl8o ad8KShjoWU9mvAq7Hc7gIpA= =C9hb -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040114222616.GC64370>