|IBM recently announced plans to release a Logical Volume Management System [LVMS] to the Linux community. While this is surely good news, and IBM is shaping up to be a major supporter of free software in general and Linux in particular, I am not convinced that IBM's LVMS will be an important addition to Linux.|
I no longer use IBM's LVMS or AIX -- and I don't miss them. LVMS does have some convenient features, such as journaling filesystems, encryption, and extendable filesystems. In my case, however, the tradeoffs more than offset the gain. I need only RAID 0+1, RAID 5, hot spares, and a few other support functions. IBM's LVMS, however, adds a significantly more complexity between the filesystem and the physical devices, and results in an environment that is both more difficult to understand and harder to precisely control. The complexity alone will greatly limit the number of systems that will take advantage of this software layer. For professional Unix shops, of course, the additional complexity isn't a very big problem.
For such installations the second problem is the important one -- and it arises from what may be the most appealing feature of this technology; the ability to resize a filesystem while it's mounted and in use. By allocating disk as needed, it becomes a simple matter to avoid under-sizing or over-sizing filesystems. You can simply allocate only the minimum amount of space necessary for each filesystem and keep the unused disk in reserve. Then, additional space can be added to only those filesystems that need it as they approach their capacity.
Using this feature, however, creates the following problems. The filesystems themselves become fragmented across a single disk as they are extended. Further, filesystems grow across multiple disks in an unplanned way. These effects result in higher seek times and, therefore, slower access to data even when only a single file is read. Worse, they limit your ability to physically isolate related files from each other so that reading a database index might interfere with reading the very database file the index points to. This sort of contention can multiply the time necessary to read data. In the case of unrelated files, the effects are less predictable, but just as real. Users might notice that a particular query varies widely in the amount of time it takes to complete when an otherwise unrelated query is happening at the same time.
While it is possible to minimize these problems with careful planning of your data layout, much of the advantage of using a resizable filesystem would be lost in that approach. Planning and good knowlege of your future requirements eliminates much of the need for dynamically resizing filesystems.
Since Linux's software RAID is much simpler than LVMS and includes some of the more valuable LVM functions already, such as multi-disk filesystems, it's probably a better solution for most users than IBM's LVMS.
This brings us to the core of my concerns about IBM's LVMS. LVMS is a complex piece of software doing a very sensitive job. Those who actually need it will be few and they will require it to be solid and proven. With several competing alternatives pulling away would-be users, the adopters of LVMS will be fewer still. Without a big base of users -- and barring a significant effort on the part of IBM -- will LVMS ever get the extensive development and testing it must have to become properly proven?
IBM's LVMS, assuming it is ported from AIX, is undoubtedly more mature and complete than the Linux LVM project. Only time will tell if the commitment and interest are sufficient to make this a usable feature of Linux.
Disclaimer: It has been years since I've used IBM's LVMS under AIX. It has had additional features added and has definitely improved in recent years. Also, the portability of the existing code may prove to be sufficient to eliminate my debugging concerns.