Future of RAIDFrame
Greg 'groggy' Lehey
grog at FreeBSD.org
Sat Jan 10 21:04:53 PST 2004
On Saturday, 10 January 2004 at 18:12:28 -0700, Scott Long wrote:
> Alexander Leidinger wrote:
>> On Sun, 11 Jan 2004 00:12:57 +0100
>> "Poul-Henning Kamp" <phk at phk.freebsd.dk> wrote:
>>> As much as I would hate to see RF and Vinum disappar from our
>>> source tree, maybe what we need to do is to kick them both into
>>> "training-camp" in p4 while you and Greg look the other way.
>>> I'd say lets kick them both into perforce and let whoever wants
>>> their hands have a go at them.
>> RF isn't working today on -current, vinum is (please don't tell me
>> something else, I don't want the system under my desk stop running on a
>> vinum volume just because you say it has to :-)). Do you really want to
>> throw your axe at vinum while it's still alive?
> Ok, stop right here. This is the third email so for that is attempting
> the debate the merits of one over the other. Spending time arguing that
> point is a waste of time. If working on RF is something that interests
> you, then show your support and say so.
On Saturday, 10 January 2004 at 16:44:10 -0700, Scott Long wrote:
> Dag-Erling Smørgrav wrote:
>> Scott Long <scottl at freebsd.org> writes:
>>> I started RAIDframe three years ago with the hope of bringing a proven
>>> and extensible RAID stack to FreeBSD.
>> I'm having trouble seeing what RF does that Vinum (or at least a
>> properly GEOMified Vinum) can't do...
> Please read the RAIDframe documents at http://www.pdl.cmu.edu/RAIDframe
> before you ask again.
People, I think we should make it clear that neither Vinum nor
RAIDFrame are perfect. We shouldn't chuck either out at the moment,
and it would be really nice, as phk suggests, to have people working
on both. Both are rather old now, but they contain good ideas. It
would certainly be an excellent idea to improve them both. We
shouldn't be trying to compare their relative merits at the moment.
Wait until they regain their strength.
I'll answer phk's suggestions separately.
See complete headers for address and phone numbers.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040111/1eb53b5d/attachment.bin
More information about the freebsd-current