From owner-freebsd-hackers@FreeBSD.ORG Wed Jan 14 14:26:22 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 ADED916A4CE; Wed, 14 Jan 2004 14:26:22 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB69B43D1D; Wed, 14 Jan 2004 14:26:20 -0800 (PST) (envelope-from grog@lemis.com) Received: from blackwater.lemis.com (blackwater.lemis.com [192.109.197.80]) by ozlabs.org (Postfix) with ESMTP id 52C902BD75; Thu, 15 Jan 2004 09:26:18 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id 7DDDF51215; Thu, 15 Jan 2004 08:56:16 +1030 (CST) Date: Thu, 15 Jan 2004 08:56:16 +1030 From: Greg 'groggy' Lehey To: Poul-Henning Kamp Message-ID: <20040114222616.GC64370@wantadilla.lemis.com> References: <20040114215347.P608@korben.in.tern> <29577.1074115952@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <29577.1074115952@critter.freebsd.dk> User-Agent: Mutt/1.4.1i Organization: The FreeBSD Project Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.FreeBSD.org/ X-PGP-Fingerprint: 9A1B 8202 BCCE B846 F92F 09AC 22E6 F290 507A 4223 cc: Mark Linimon cc: hackers@freebsd.org cc: Robert Watson 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 22:26:22 -0000 --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--