Date: Wed, 14 Jan 2004 22:27:25 +0100 (CET) From: Lukas Ertl <l.ertl@univie.ac.at> To: Robert Watson <rwatson@freebsd.org> Cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) Message-ID: <20040114215347.P608@korben.in.tern> In-Reply-To: <Pine.NEB.3.96L.1040112100911.91469l-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040112100911.91469l-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040114215347.P608>