Choosing a volume manager for 2.5

Choosing a volume manager for 2.5

There are many nice elements to the design of EVMS, and the model that it presents to the user is easy to grasp. But EVMS duplicates (and extends) much of the functionality of existing kernel features such as elements of the block layer, MD, etc. Unfortunately, whenever a project reaches the scale of EVMS, there is a strong tendency for the developers to go off and work independently constructing a massive edifice. The reason for this is obvious: it is much easier to write code in a way that steers clear of potentially controversial changes to the kernel core and avoid having to argue for each incremental change on its merits. Hence we have a half-dozen journalling filesystems that share no journalling code, despite Stephen Tweedie's best efforts in creating JBD. :-( And this is not a new phenomenon -- consider the I/O queueing functionality only recently moved out of the SCSI subsystem into the block layer.

Much as I'd like to have advanced volume management on my machines, I'm rather suspicious of large volumes of new code that haven't been vetted, in small, digestible pieces, by the likes of Linus, Alan, Al Viro, Dave Miller, Andrew Morton, Christoph Hellwig, etc. This is not just a question of whether IBM or any other firm has capable developers. The kernel is changing rapidly, and subtle changes to the semantics of interfaces occur frequently (locking, scheduling, MM, I/O, ...) -- it seems best to pass code by the developers who are thrashing the core and have their antennae tuned to the particular aspects of the code with which they are intimate.

XFS is a great example: it was a pre-existing code base, for which SGI had to create a lot of "glue" infrastructure, e.g. pagebufs, and EA/ACLs. It took a long time, but XFS was split into pieces, much of the required functionality re-implemented by others in a (Linux-centric) manner that benefits all kernel users of the vfs, page-cache, and block i/o, and the resultant pieces slowly merged. The kernel is *much* better for the effort.

As an aside: I am still fascinated with how Linus put much of the 2.3.x page cache and scalability work in the hands of Ingo, a relative newcomer at the time, or how Andrew Morton has held sway over the VM and I/O rewrite in 2.5.x. Why does Linus trusts folks like Al Viro, Andrew Morton, and Ingo Molnar to thrash the internals of the kernel core? Just look at their methodology, and the effect it has on the quality of their output ...