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

In message <20040111051649.GK7617_at_wantadilla.lemis.com>, "Greg 'groggy' Lehey" 

>> 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.
>
>Hmm.  I can't see why they have to disappear from the source tree, [...]

I forgot to mention on rather important factor in this equation:

If nothing happens, vinum is going to break even more very soon.

The plan for the cleanup of the buffer cache, such as we drew it
up at BSDcon, says that filesystems will go directly to GEOM for
disk service rather than detour through the vnode layer, SPECFS and
then to GEOM.  (This is not a matter of our choice of bike-shed
color, this is a matter of SMP performance, locking sanity and
buf/VM performance.)

The first step of this has actually happened with the swap_pager
which now goes directly to GEOM, and that is why you cannot put
your swapspace on a vinum volume any more.

The next target is UFS.

The softupdates and snapshot support, because of the way the buffer
cache interacts with SPECFS, has callback hooks in SPECFS which do
not belong there.

The next step is to move UFS to go directly to GEOM and at the same
time pull the callbacks out of SPECFS and into UFS (FFS really)
where they belong.

Once I proceed with that step, you cannot mount UFS on a vinum
volume.

After that, the rest of the filesystems will follow, one by one.

The question in my mind is:  What if vinum is not fixed by then ?

If it is decided to leave vinum in the CVS tree at this point in
time, do we all agree and accept that if not fixed by then, vinum
gets disconnected from the build when we proceed with the buffer
cache cleanup ?

To give an idea about the relative urgency, we are probably talking
february or march this year.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.