Mastering the Enterprise Volume Management System

The Enterprise Volume Management System, or EVMS, is a disk, partition, and file system manager for Linux that claims to be a comprehensive tool for all disk management tasks. I ran across EVMS and found the idea appealing, so I decided to try it out. I’ve been working with it for a couple of weeks now, and this article describes what I found.

What EVMS Does

EVMS combines disk, partition, file system, and logical volume management in a single, unified interface. It also adds some features not readily available in other tools, such as drive linking and bad block relocation.

EVMS takes the place of a diverse set of tools, such as fdisk, parted, mkfs, fsck, and RAID and LVM tools. In some cases EVMS does the work of these tools itself, and in other cases it calls on them to do its work. Either way, you won’t need to run them any more. Here are some of the things you can do with EVMS:

Partition management: Create, destroy, and resize disk partitions. You can stick with the old familiar but archaic partitioning scheme, with its primary and extended partitions, but EVMS also offers other partitioning schemes with more modern features, such as partition table redundancy and discoverable partitions.

File system management: Create, destroy, check, fix, mount/unmount, and resize file systems, wherever those operations are supported by the file system type. EVMS knows about Ext2/3, NTFS, ReiserFS, JFS, XFS, and Linux swap file systems. It doesn’t support (or even mention) any of the FAT family of file systems, but not many people will cry over that. EVMS automatically coordinates file system operations with other disk and volume management tasks, for example by expanding or shrinking a file system at the right time when a disk volume is expanded or shrunk.

Logical volume management: You can place your disks or partitions into a storage pool (called a volume group in LVM, or a container in EVMS), and then export logical disk volumes that draw from the pool. It becomes easy to create new disk volumes or expand or shrink existing volumes, just by drawing from or returning storage to the pool.

Software RAID: Combine disks or partitions into mirrored, striped, or parity arrays (RAID-0, -1, -4, or -5), activate and deactivate arrays, add spare disks, and remove bad disks.

Bad block relocation: Add a software bad block relocation (BBR) layer over any disk or disk segment. The device mapper will set aside some spare disk blocks, and whenever a write error is detected, mark the block in question as unusable and transparently substitute one of the spare blocks. I believe that BBR has been a standard feature of hard drive firmware for several years now, so this feature may not be as important as it sounds, but it is an extra layer of protection.

Drive linking: The opposite of partitioning: join disks or partitions into a single logical disk.

All of the above components can be combined in almost arbitrary ways, to give you a staggering amount of flexibility in configuring your storage. To get an idea of the possibilities, consider the following diagram (reproduced from the EVMS architecture overview) of a sample storage layout. Here “md” represents a multiple device (RAID) array, “lvm/group1” is an LVM volume group, and BBR indicates a bad block relocation layer. The top row contains the exported logical volumes: block devices on which you can build filesystems.

Most of EVMS’ functionality relies on two Linux kernel modules: the device mapper, which maps logically contiguous block devices onto arbitrary collections of disk extents, and the multi-disk driver, which joins block devices into RAID arrays. Because of this, EVMS only runs in Linux (kernel 2.4 or later).

Installation

Unless your kernel happens to already include EVMS support, you’ll have to patch, configure, and build a custom kernel in order to use EVMS. The EVMS web site includes a step-by-step guide to installing the user-space tools (probably available as a package in your distribution), configuring your kernel, and converting your existing disks and partitions into EVMS volumes.

There are a couple of hurdles to clear during the installation. First, if you’re running a 2.6-series kernel and want to use EVMS to manage any part of the disk drive that includes your root file system, then you’ll need to either apply an additional kernel patch, or else boot from an initial ramdisk that activates EVMS before any of the file systems on that disk are mounted. This is because of a conflict over who “owns” the disk drive: the kernel proper, or the device mapper module. Be sure to read carefully the section on “Building the Kernel,” and especially the part about the “BD claim patch,” in the installation guide.

Second, if you want to manage your root file system as an EVMS volume, you’ll have to create and boot from an initial ramdisk. Again detailed instructions are provided, along with a sample initial ramdisk that should work for most installations. This method also takes care of the disk ownership problem described above. Still, this is fairly advanced stuff, and it isn’t required at all. You can leave your root file system on a regular old disk partition, and still use basic EVMS capabilities, such as partition and file system resizing, on that partition. You won’t be able to use EVMS’ more advanced capabilities, such as bad block relocation, RAID, and drive linking, on that partition.

If you do decide to put your root filesystem on an EVMS volume, then you must keep an EVMS-capable bootable rescue CD on hand. If you don’t, and if something goes wrong and you can’t boot normally, then you won’t have access to any of your EVMS volumes. Your only option will be to wipe and reinstall. Don’t take the risk: either download and burn a rescue CD from SystemRescueCD (there are many rescue CDs, but this one includes EVMS capability), or roll your own. You’ll also need to boot from your rescue CD in order to perform any offline management tasks on your root file system.

One last consideration is that boot loaders in general, and LILO and GRUB in particular, don’t understand anything about the Linux device mapper; they only know about simple disk partitions or segments. So, you should not try to manage your boot partition as an EVMS volume, except possibly as one segment of a RAID-1 (mirrored) array.

A Choice of Interfaces

Once you’re finally ready to start using EVMS, you have a choice of three interfaces: command-line, full-screen text using ncurses, and a GUI using GTK. All three interfaces offer essentially the same set of commands and capabilities, and the text and graphical interfaces are laid out identically, so once you learn one it’s easy to use the others.

The GUI is easiest to navigate, so I recommend that you use it while you learn your way around EVMS. But the text interface is a valuable middle ground between the GUI and command line, especially for performing system management tasks, where an X server is usually not available. Some disk operations will require you to drop down to single-user mode, and here the text interface is welcome and comfortable. As another example, I’ve built a custom rescue CD for my file server. The CD has to include EVMS capability, and it doesn’t include X. So here again the text interface is welcome.

The command-line interface is intended for scripting, according to the EVMS documentation. But I won’t get anywhere near that. EVMS is very good about preventing you from making stupid mistakes, but if you tell it to obliterate a file system on the wrong partition, it will. In the text and graphical interfaces you’ll get some feedback and a last chance to bail; but write some wrong logic into a script, and you can destroy a lot of data in a very short amount of time.

Starting to Use EVMS

When you first start to use EVMS, it can be a little overwhelming. One reason is that the authors have developed a whole new set of terminology for all of the many types of storage objects that EVMS uses, in order to avoid confusion with terms used, sometimes inconsistently, by other disk management software. For example, instead of partitions, EVMS uses a somewhat more general notion of disk segments. Logical volumes and volume groups, from Linux’ Logical Volume Manager (LVM), become regions and containers. The new terminology is all clearly explained and related to the more familiar ideas, right at the start of the EVMS manual. Still, it takes time to master.

Another hurdle is the large number of tabs in the GUI. At first it’s hard to know where to look, and where to perform the operations you want to perform. This is probably unavoidable; it’s a result of the complexity and power of EVMS. One thing that helped me when I finally noticed it is that the highest level objects (volumes: the block devices that you build file systems on) are at the left, and as you move toward the right you move to lower level objects, until you arrive at disks, which (thankfully) correspond to physical disk drives.

All of this detail was confusing to me at first. But I practiced using the GUI to create and destroy objects in some spare disk space; related the objects in the GUI to old familiar concepts from LVM; reread the manual; and spent some time looking at the sample diagram. After a while, it all became clear.

Power Grows on You

Did you know that it’s possible to move the data in a live file system from one disk partition to another? That’s right: you can move a file system while leaving it mounted for reading and writing. At least, you can if your file system is built on an LVM or LVM2 logical volume. EVMS knows which types of volumes support this operation, and allows you to do it when they do.

Did you know that you can expand some file systems without dismounting them? Not all file systems support this, but when they do, EVMS allows you to do it. ReiserFS, for example, provides the capability to expand a mounted file system, and EVMS knows it and allows you to use it.

These examples illustrate the core strength of EVMS: it ties together the capabilities that are already available in many different tools, into a coherent framework accessible through a single, consistent interface. It also makes disk management easier, by taking care of the details. And it makes disk management safer, by knowing what operations you can’t or shouldn’t do, and not allowing you to do them.

Here’s another example. Have you ever had to shrink a disk partition and the file system that lived on it? If you haven’t, take it from me: it requires great care and carries a high risk of destroying your data. You have to shrink first the file system and then the partition, paying careful attention that the numbers and sizes of blocks are the same in both operations. Different commands are required to resize the partition and each type of file system, with different options, and sometimes different default block sizes. Issue a wrong command, and your data is history. This is exactly the sort of dangerous and error-prone task that software should handle for us, and EVMS does. Just tell it to shrink (or expand) a volume, and it takes care of the details. The task is both easier and safer.

Uh Oh

If there’s a drawback to all of that power, it’s that it can lead to overconfidence. During my testing of EVMS, I got to be pretty bold about moving live file systems around. Then, during the third time I tried it, as a move operation was about 75% complete, I fired up a heavyweight email client. Bad news: first the client started to show me corrupted mail folders, and then my entire system locked up hard. Even the magic SysRq didn’t work, so the kernel was in a very bad state. I had to press the reset button. The move operation hadn’t completed, and I thought my home partition was toast. But to my surprise, when I rebooted from my rescue disk (remember I said you had to have one of those?) and ran fsck, everything was fine; the volume was clean and in its original location. I reran the move operation (this time with the volume unmounted), rebooted, and to my great relief, found that all of my data was intact. Later, I read in the manual that this behavior is by design. (I live on the edge, so you don’t have to.)

So I got away with it that time, but the old lesson was reinforced: back up your data before you start rearranging disk volumes. I know, every partition manager tells you this, and after a while you start to ignore it. But even with a high-quality product such as EVMS—not to mention a certain popular graphical partition manager, which once trashed my boot partition while moving it, and it wasn’t even mounted—the risk of data destruction is non-negligible. And moreover, just because EVMS allows you to do something cool, doesn’t mean you should do it. It’s still safer to dismount your volumes before moving them.

Breaking Old Habits

If you’re like me, you’ve spent many hours over the years repartitioning disks the hard way: moving your data to some free space, verifying the copy, repartitioning, creating a new file system, moving the data back, and verifying the copy again. It’s slow work, and every time you get a new disk or your space requirements change (/home filled up again?), you have to do it again. How much space do you need for /home this time? And do you really need separate partitions for each of /boot, /usr, /usr/local, /var, /tmp, /opt, and /home, as I’ve seen recommended? Good grief. Partition like that, and you’ll be back in a week changing it all around again.

Logical volume management, of the kind provided by LVM or EVMS, is the tool to free us from this drudgery. It lets us take a high-level view of our storage, and forget about the details. If /home is nearly full and you need to take some space from /var, don’t repartition; just tell EVMS to reallocate the space. Or if you’ve added a new disk, you don’t have to move all of /home onto the new disk in order to give it room to grow; just tell EVMS to append some of the new empty space onto /home. /home may end up spread over a collection of disk segments on several disks, but you don’t have to care because the device mapper presents them to you as a single logically contiguous disk extent. And if you really want the fine-grained control that you get by creating all of those partitions, then at least the weekly chore of reallocating the space will be easier.

There are cases where you’ll want to specify which physical disk drive a volume should live on. You may want to keep your root file system on your fastest drive, for example, or move all the data off of a drive before removing it from your host. EVMS allows you to do all of these things; you have complete control. You can build a volume on top of an LVM region for greater flexibility, or keep it on a particular disk segment for greater control.

Documentation and Support

EVMS comes with a manual, an architecture overview, and step-by-step guides to installing the software and converting your existing partitions into EVMS volumes. The documentation is well written and illustrated, clear, and generally complete. The manual seemed a bit sparse to me at first, but I usually found that the information I needed was there; I just needed to go back and read it again.

The text and graphical interfaces both offer help text in action dialogs, but it doesn’t work in the text interface, and in most cases I found the help to be generic and not especially useful anyway. For example, when I was creating a new disk segment using the GPT segment manager, EVMS asked me if I wanted the new segment to be a “System Partition.” I didn’t know what that meant, the manual didn’t say, and the help text just told me that this was a dialog where I could choose options. Not very helpful, but fortunately not crucial to me in that case.

The EVMS developers monitor the EVMS mailing list, and are highly responsive to questions and bug reports posted there.

Overall Quality and Usability

EVMS is open source software, hosted on Sourceforge. But this is not someone’s weekend hobby. It’s professional quality software. In two weeks of heavy use I found it to be stable and free of all but minor bugs. This is especially important in such a sensitive application, where a bug can cause catastrophic loss of data.

Development of EVMS is funded by IBM, which has a team of developers fixing bugs, developing new features, and answering queries on the EVMS mailing list. This level of professional development effort is apparent in the multiple parallel interfaces, good documentation, and elegant back-end design, which probably in itself accounts for some of the application’s stability.

The GUI is pleasant to use, with a clean look and logical layout. As I mentioned before, the parallel layout of the text and graphical interfaces helps in learning to use both.

If I could see the GUI improved in one area, it would be in helping the user to visualize all of the complicated relations between the many storage objects at different levels: disks, segments, containers, regions, drive links, and RAID arrays. If you want to find out about a particular storage object, the GUI will show you which other objects it’s built from, but this is only a small part of the whole picture. What would really be useful is for the GUI to automatically create complete object diagrams like the sample diagram above.

Conclusion

After working heavily with EVMS for a couple of weeks, I’ve concluded that it rocks. Its capabilities are comprehensive, and its design, interface, documentation, and support are of high quality. EVMS may be designed for enterprise use, but home power users will not want to miss out on its capabilities. Once you get over the hurdles of installing and learning to use it, EVMS will probably be the only disk management software you’ll ever need.

About the author:
Andrew E. Schulman is a statistician and programmer at the U.S. Environmental Protection Agency in Washington, DC. The opinions expressed in this article are those of the author, and not necessarily those of the Agency.

---

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.