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

[Robert Watson]

On Mon, 12 Jan 2004, Mark Linimon wrote:

> > If nothing happens, vinum is going to break even more very soon.
> 
> No ... if you do a commit that changes the code assumptions upon which
> vinum was built, vinum will break.  vinum is not going to "magically"
> break by itself. 
> 
> This gets back to a problem with the FreeBSD development model:  people
> who commit changes that break things in other parts of the system do not
> automatically get assigned the responsibility to fix them.  Now, there's
> no way to impose something like that requirement on a cooperative
> anarchy, so I am not playing the "let's reorganize"  card -- I think
> most of us would agree that "that dog won't hunt" as we say down around
> these parts. 
> 
> But, in the real world of software engineering, He Who Breaketh It, Must
> Fixeth It. 

Well, actually, it's not quite that way.  The reality is that every major
component in a system needs someone with expertise in it, who is willing
and available to maintain the system across infrastructural changes. Vinum
has made it over smaller API bumps without a maintainer: the move to
devfs, etc.  However, to make it speak GEOM requires someone highly
familiar with Vinum, and with the time available to do it.  If we want to
enhance the architecture of FreeBSD for improvements in performance,
stability, and long-term maintainability, there will necessarily be
structural changes that require a distributed update of the system. 
FreeBSD is of sufficient size that no one person will be able to make this
sort of change alone, which is one of the important reasons to have a
software maintenance model that reflects that.  Our notion of software
maintainance could certainly use some further evolution, but I think there
are some existing intuitions.  Vinum is a highly complex software module,
and *must* have an active maintainer in order to survive structural
operating system changes. 

Greg has recently posted to arch@ saying "What's the future of Vinum",
indicating an intent to continue to enhance Vinum, and received a number
of e-mails regarding how to adapt Vinum for GEOM.  I sent him an e-mail in
which I laid out a spectrum of possibilities, ranging from the minimalist
to a complete transformation of Vinum into a GEOM module.  Greg has
indicated he plans to work on Vinum further, so I think the best we can do
is provide support and encourgement.  The minimalist approach appears to
be viable (although there are some risks), and someone highly familiar
with Vinum (such as Greg) can probably make the changes in short order.
He's currently at a conference, but my hope is that when he gets back,
he'll evaluate some of the approaches we've described, and pick one.  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.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research