posted by Andrew Schulman on Wed 13th Apr 2005 19:46 UTC
IconThe 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.

Sample storage layout with many kinds of storage objects

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


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.

Table of contents
  1. "EVMS, Page 1/3"
  2. "EVMS, Page 2/3"
  3. "EVMS, Page 3/3"
e p (0)    11 Comment(s)

Technology White Papers

See More