Date: Wed, 7 Jan 2004 16:52:52 +1030 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: FreeBSD Architecture Mailing List <arch@FreeBSD.org> Subject: Vinum and GEOM: the future Message-ID: <20040107062252.GQ7617@wantadilla.lemis.com>
next in thread | raw e-mail | index | archive | help
--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+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040107062252.GQ7617>