--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wednesday, 15 October 2003 at  8:43:26 -0700, Jason Thorpe wrote:
> On Wednesday, October 15, 2003, at 08:25  AM, Chuck Silvers wrote:
>
>> now that we've stated our diametrically opposed positions,
>> could you give some explanation of why you think vinum's approach
>> is wrong, and why (I assume) you think raidframe's is better?
>
> Vinum blends redundancy with virtualization.

Well, it includes both.

> The two things are logically independent.

I think it's fair to say that the independence is visible in Vinum.
One of the issues, which I'll address below, is that people don't seem
to know much about Vinum.

> I would feel a lot better about Vinum's approach if all of the RAID
> bits were ripped out, and it simply did virtualization.

One of the main reasons I considered incorporating Vinum into NetBSD
was because you were complaining a few months back about how bloated
RaidFrame is.  Part of this lack of bloat is the way it's constructed.

> (Then we need to address the actual implementation of
> virtualization, but that's a separate issue...)

In principle, yes.

On Wednesday, 15 October 2003 at 11:33:28 -0400, Jim Wise wrote:
>
> On Wed, 15 Oct 2003, Lennart Augustsson wrote:
>
>>> No, I don't think there was enough discussion.
>> What Jason said.
>
> Me four.  As far as I can tell, vinum brings one feature to the table
> which was not provided by Raidframe (named volumes, which are
> approximated by RF autoconfig in the absence of `last configured as'
> conflicts), but ties this feature to a very complex and over-specialized
> hierarchy of components.

What complexity do you see?

> While it _does_ provide much of the functionality of raidframe, that
> functionality is divided among levels of the Vinum design in such a
> way that only certain of the combinations of operations provided by
> RF are possible.

Yes.  Depending on your viewpoint, this is an advantage or a
disadvantage.

> Raidframe's basic (and very clean) approach of assembling block
> devices into other block devices which may then themselves be used
> as components is _much_ more flexible, and IMHO fits much better
> into the overall system design.

How does this approach differ from Vinum?  That's what it does too.

On Wednesday, 15 October 2003 at 15:49:42 +0000, Thor Lancelot Simon wrote:
>
> I don't necesarily think that Vinum is right, either.  My personal
> preference would be for a stackable framework of simple, fast storage
> management modules that provided the flexibility of RAIDframe while
> being easier to maintain and offering better performance, especially on
> platforms with expensive context switches.

What about GEOM?

> But it's interesting to note that Vinum does work more like at least
> some vendors' storage frameworks than RAIDframe does; if it's wrong,
> too, what that's really saying, ISTM, is that we've got *two*
> examples of "wrong" in our tree.  That's not a great long-term
> solution but neither is what we had before.

Vinum has been around for a long time.  It's almost certainly in need
of restructuring.  I think it would be a lot easier to restructure it
than it would be to restructure RaidFrame.

On Wednesday, 15 October 2003 at 21:00:55 +0100, David Laight wrote:
> On Wed, Oct 15, 2003 at 12:47:43PM -0700, Jason Thorpe wrote:
>>
>> On Wednesday, October 15, 2003, at 08:53  AM, John Hawkinson wrote:
>>
>>> Perhaps there was insufficient guidance from the sponsors?
>>
>> That's an understatement.  AFAIK, there was no discussion on tech-kern
>> about:
>
> 0: what vimun is (what does the acronym stand for even!)

Vinum is the Latin word for wine.  Veritas is the Latin word for
truth.  There's a relatively well-known Latin proverb "In vino
veritas" (in wine lies the truth) (and vino is the ablative case of
vinum).

On Wednesday, 15 October 2003 at 12:47:43 -0700, Jason Thorpe wrote:
>
> On Wednesday, October 15, 2003, at 08:53  AM, John Hawkinson wrote:
>
>> Perhaps there was insufficient guidance from the sponsors?
>
> That's an understatement.  AFAIK, there was no discussion on tech-kern

I sent mail to tech-kern some months back. I was somewhat disappointed
by the lack of interest.  Since it had been discussed before, though,
I saw no reason to force more discussion.

> about:
>
> 	1. How Vinum works.

This is described in my USENIX paper from 1999.  I'm currently in the
process of updating it, but the principles are all visible in
http://www.vinumvm.org/vinum/intro.html.

> 	2. Why we want it (i.e. what problems does it solve).

I suppose the big one was your complaint about RaidFrame's
performance.  It remains to be seen how much better Vinum performs,
but I'm expecting it to be better.

> 	3. What are the alternatives.

Are there further alternatives?  When you sent your message out in
January, no others were mentioned.

> 	4. How it is configured.

In the paper, and also (of course) in the man page.  Create a
configuration file describing the objects and use the 'vinum create'
command to add to them.  Vinum stores its current configuration on
each drive, so you don't need to keep the config file around.  This
also means that you can remove drives, replace them elsewhere and
still have a functional Vinum configuration.

> 	5. How it is integrated into the rest of the system.

In the paper.  Basically, it's a block/character device shim: looks
like a block/character device to the bio system, interfaces to
block/character devices below.

So how do we get this stuff back on track?  How about letting me
finish the port, then we can talk about changing it.

Greg
--
See complete headers for address and phone numbers.

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iD8DBQE/jkuXIubykFB6QiMRAkHzAJwLeOHBRhHiV+cQVsJEzG/aF0rIfQCfWi4n
Sw1dDCegMlYUzy+8ab6HdrQ=
=aKBe
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--