Future of RAIDFrame and Vinum (was: Future of RAIDFrame)

[Greg 'groggy' Lehey]

On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote:
> In message <20040114215347.P608 at korben.in.tern>, Lukas Ertl writes:
>> On Mon, 12 Jan 2004, Robert Watson wrote:
>>
>>> I think the right strategy is to follow the minimalist approach now
>>> (adopt the disk(9) API, rather than having Vinum generate character
>>> devices) so that swap works on Vinum again, and so that when UFS moves
>>> to speaking GEOM there's no loss of functionality.  If we want to
>>> completely reimplement Vinum, we should do that separately so as to
>>> avoid loss of functionality during structural changes.
>>
>> As many ways lead to Rome, how about the following scenario.  I don't know
>> if it's a clever way to do things, and I don't know if it's even possible
>> to with GEOM, so some input is appreciated.
>>
>> *) Have separate GEOM classes for each of the different vinum objects
>>   (drive, sd, plex, volume).
>> *) Let the drive geom taste the slices configured for vinum, read the
>>   on-disk config and then spawn the necessary other geoms (I'm not sure
>>   if the latter can be done in GEOM).
>> *) I think this is a clean implementation, since the GEOM framework offers
>>   all the "background" needed to transform the IO requests.
>> *) It would also be a good way to clean up the vinum code.
>
> It is possible in GEOM, but I am not convinced that fragmenting into
> this many GEOM classes can be classified as an easy path to go.

I think it's probably a good ultimate aim, but I don't think it should
be the first step.

> I think for now the important thing is to get the people interested
> on this collected on a mail-alias, and for them to discuss how the
> can work together to make something happen.  After that, try to
> define "something" closer.

A mailing lists exists.  vinum-devel at auug.org.au.  If somebody wants
to put in a FreeBSD version, that wouldn't be a disadvantage.

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-hackers/attachments/20040115/15f678ae/attachment.bin