From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 13:27:50 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBD4C16A4CE; Wed, 14 Jan 2004 13:27:50 -0800 (PST) Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F64D43D8C; Wed, 14 Jan 2004 13:27:39 -0800 (PST) (envelope-from l.ertl@univie.ac.at) Received: from wireless (adslle.cc.univie.ac.at [131.130.102.11]) i0ELRT8U406130; Wed, 14 Jan 2004 22:27:31 +0100 Date: Wed, 14 Jan 2004 22:27:25 +0100 (CET) From: Lukas Ertl To: Robert Watson In-Reply-To: Message-ID: <20040114215347.P608@korben.in.tern> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-DCC-ZID-Univie-Metrics: imap 4244; Body=0 Fuz1=0 Fuz2=0 cc: Greg 'groggy' Lehey cc: Mark Linimon cc: Poul-Henning Kamp cc: hackers@freebsd.org Subject: Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 21:27:51 -0000 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/