From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 22:22:59 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EE9F16A4CE for ; Tue, 6 Jan 2004 22:22:59 -0800 (PST) Received: from ozlabs.org (ozlabs.org [203.10.76.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F03143D2F for ; Tue, 6 Jan 2004 22:22:57 -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 8A7D92BD73 for ; Wed, 7 Jan 2004 17:22:54 +1100 (EST) Received: by blackwater.lemis.com (Postfix, from userid 1004) id B67F251216; Wed, 7 Jan 2004 16:52:52 +1030 (CST) Date: Wed, 7 Jan 2004 16:52:52 +1030 From: Greg 'groggy' Lehey To: FreeBSD Architecture Mailing List Message-ID: <20040107062252.GQ7617@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QOaciPm+FYh5cTV+" Content-Disposition: inline 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 Subject: Vinum and GEOM: the future X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2004 06:22:59 -0000 --QOaciPm+FYh5cTV+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Vinum and GEOM overlap significantly in their features, and they do some things not only differently but in an incompatible manner. The development of GEOM has resulted in Vinum features atrophying and rotting. For example, at present, it's not possible to put swap on a Vinum volume, due to a change in the swapon() code which requires GEOM. Vinum was written at a time where many of its features were not available in any other form. With the advent of GEOM, that has changed. What should we do with Vinum? The obvious options are: 1. Ditch it. It's served its purpose, and there are better alternatives. 2. Keep it alongside GEOM, and maintain code such as the swapon() code to handle both. 3. Modify it to understand GEOM. As I'll explain, I think that the only serious option is (3). Vinum needs to be modified to work with GEOM, at least in those areas which overlap. One problem I have is understanding the relationship between GEOM and Vinum. Yes, it's easy to understand statements (from geom(4)) like: In the fixed hierarchy above it is not possible to mirror two physical disks and then partition the mirror into subdisks, instead one is forced to make subdisks on the physical volumes and to mirror these two and two resulting in a much more complex configuration. GEOM on the other hand does not care in which order things are done, ... It's also very clear that GEOM offers significant advantages in this area (but also more room for users to shoot themselves in the foot; the quote above continues: "the only restriction is that cycles in the graph will not be allowed."). The question I have is: what other advantages does it offer? I'm currently writing a paper for presentations to the Linux.Conf.Au in Adelaide next week (http://lca2004.linux.org.au/, in case you're interested, and yes, they specifically asked for a paper about Vinum. Go figure), and I've come up with the following list of Vinum features:=20 - Online configuration via the vinum utility program. - Automatic error detection and recovery where possible. - State information for each object. This enables Vinum to function correctly even if some objects are not accessible. - Persistent configuration. Each Vinum drive stores two copies of the configuration, so the system can start up automatically. The configuration includes state information, so any degraded objects will remain so over a reboot, or even when moved to a new system. - Support for Vinum root file systems. - Online rebuild of objects. Interestingly, none of these touch GEOM as far as I can see. Am I missing something? Based on this understanding, my intentions for Vinum currently don't go beyond replacing the following: - Replace the objects volume, plex and subdisk with a corresponding geom. I expect this to enable a more arbitrary means of joining together the objects, but that's about all. - Replace the ioctls with gctl_s. This seems to be more cosmetic than functional, though also a good idea. This will certainly be worthwhile, but somehow I was expecting more. Can anybody suggest other things that could be changed with benefit? Greg -- See complete headers for address and phone numbers. --QOaciPm+FYh5cTV+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (FreeBSD) iD8DBQE/+6W8IubykFB6QiMRAh1dAKCUDONVoK2uF646FolDst79gwR24ACfc5+6 2hRth80ABV3yoQmbPx+Hjwc= =EJes -----END PGP SIGNATURE----- --QOaciPm+FYh5cTV+--