Updated geom_vinum

[Greg 'groggy' Lehey]

On Thursday, 22 January 2004 at 17:12:53 +0100, Lukas Ertl wrote:
> Hi,
>
> I've created an updated geom_vinum.  It now understands concatenated
> plexes (a plex with more than one subdisk), and mirroring (a volume
> with more than one plex) should also work, but I've not tested the latter.
>
> An updated "GEOM screenshot" can be found at
> <http://mailbox.univie.ac.at/~le/geomvinum.ps>, and the sources are at
> <http://mailbox.univie.ac.at/~le/geomvinum.tar.gz>.

I've taken a look at this, and it's really impressive.  On the other
hand, you've effectively discarded the original Vinum code and
replaced it with something a lot more simple.  I'm not sure that this
is the most appropriate way to proceed.  In particular, the code which
maps incoming requests to outgoing requests reads:

/*
 * XXX: This needs a _lot_ of work.
 *
 * Basically, we have to cope with three kinds of plexes: concat, striped,
 * and raid5.
 * Then, we have to cope with requests that overlap two or more subdisks.
 */
static void
g_vinum_plex_start(struct bio *bp)
{

This is a great understatement.  This code is some of the most complex
I have ever written.  I'm not saying that you can't do better, but it
seems a waste of time to reinvent the wheel.  Take a look at
vinumraid5.c and vinumrequest.c for an example of how complicated it
can be.

The other thing that strikes me is that you've greatly simplified the
object structures (originally in vinumobj.h, now in g_vinum_var.h).
While a lot of things go away as the result of GEOM, others don't,
like the I/O stats and revive parameters for example.  It's possible
that you're planning to put them back in, but this seems like a lot
more work than necessary.

Also, I'm not sure that changing tables to lists is the best way to
go: each request will have to go down multiple levels of list to find
the appropriate object.  I'm prepared to be proven wrong on this one,
however: certainly enlarging tables has been one of the biggest
problems in the current Vinum implementation.

In any case, I have some time for about a week now.  We should
probably discuss offline how to proceed.

Greg
--
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20040124/aadb3fb7/attachment.bin