Choosing a volume manager for 2.5 [LWN.net]

As the feature freeze date gets closer, people are starting to get worried about some of the unresolved issues in the 2.5 series. At the top of the list, currently, is volume managers. The LVM code in the 2.4 kernel is not much loved by kernel developers; it has gone unmaintained in 2.5 and simply does not work. One thing that everybody seems to agree on is that LVM has reached the end of its life and needs to be removed.

But that, of course, begs the question of what will replace LVM. There are two contenders out there:

LVM2 is a new version of LVM, reimplemented from the ground up by Sistina Software, which also wrote the original LVM. LVM2 is actually the name given to the user-level interface; the kernel code for LVM2 is called the "device mapper" or "DM".
The Enterprise Volume Management System (or EVMS) is a new, independent development from IBM.

Both volume managers have been proposed for inclusion into 2.5 as replacements for LVM. There is currently very little consensus on which, if either, should go in, and Linus has stated that he is undecided on the issue.

LVM2/DM is the smaller and simpler of the two volume managers. Its goals are to be a cleaner, better implementation of LVM, so it does not add a great many features. It can combine volumes in a linear (appending one partition to another) or striped (interleaving data across partitions) manner, but does not support higher-level RAID features. The lack of RAID 4/5 support is not necessarily a problem, since the kernel "md" driver provides those capabilities. LVM2 also does not try to understand the filesystems on the volumes it manages, so changing the sizes of volumes can be a multi-step process. LVM2 is backward compatible with LVM, and provides a very similar interface to administrators.

EVMS is a much larger, more complex development. It supports RAID 4 and 5, and other features such as bad block remapping. EVMS comes with a comprehensive graphical interface. It also can work with several filesystem types to make filesystem resizing easy. From the user level, EVMS comes across as a far more complete tool.

There is substantial resistance in the kernel hacker community to merging EVMS, however. A number of coding style issues have been raised; for example, the declaration of static variables within header files is considered to be in poor taste. There are objections to the duplication of the RAID functionality already provided by the md driver. EVMS also hides the internal structure of its volumes. Imagine creating two large volumes by combining two drives (for each) in a linear mapping, then making one big volume by striping across the two linear volumes. The internal, linear volumes would not be visible as separate devices. Critics of this implementation dislike the duplication of code (against the block layer) implied by creating a new type of hidden block device; it also complicates operations that need to be performed directly on the internal devices. So there has been pressure to expose the internal devices, or, even, to work many of these volume management functions directly into the block layer API.

LVM2 has not been subjected to the same level of criticism; the consensus seems to be that the code is relatively clean and correct. The level of capability offered by LVM2 is lower, however.

The development teams for both EVMS and LVM2 have stated their willingness to address complaints in order to get their projects merged. The problem, of course, is that the feature freeze date is getting closer, and neither project will be "complete" by then. Some developers are talking seriously about merging neither volume manager, and simply doing without until the next development series opens.

Releasing a stable kernel without a logical volume manager is probably not a realistic option, however. Something will probably go in. Linus stated in the 2.5.42 announcement that he was leaning toward EVMS; EVMS also appears to be the choice of people who use volume management, as opposed to those who have to deal with the code. So the odds probably favor an EVMS merge, but it is far from a sure bet at this point.

(Log in to post comments)

Choosing a volume manager for 2.5

Posted Oct 15, 2002 23:28 UTC (Tue) by brugolsky (subscriber, #28) [Link]

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 ...

Choosing a volume manager for 2.5

Posted Oct 17, 2002 14:03 UTC (Thu) by DancingProg (subscriber, #4816) [Link]

I'm not quite sure if you are praising or damning Al, Ingo, et a..
Could you explain what you meant by "their methodology"?

Thanks.

Choosing a volume manager for 2.5

Posted Oct 17, 2002 19:45 UTC (Thu) by brugolsky (subscriber, #28) [Link]

Oh, it's definite praise. Read the lkml and peruse www.bkbits.com and you'll see that the best kernel hackers do their work incrementally, submitting testable and human-digestible patches that change only a handful of things at a time. They expose their work to daily criticism, and solicit constant feedback. They test their code, or work closely with others who test it. They also find time to read and critique the code of others. Consequently, Linus delegates a lot of responsibility to them.