 | Level: Introductory Daniel Robbins (drobbins@gentoo.org), President/CEO, Gentoo Technologies, Inc.
01 Oct 2002 In the multi-part "Advanced filesystem implementor's guide", Daniel Robbins shows you how to use the latest filesystem technologies in Linux 2.4. Along the way, he shares valuable practical implementation advice, performance information, and important technical notes so that your new filesystem experience is as pleasant as possible. In this article, Daniel introduces the Enterprise Volume Management System (EVMS) for Linux. He explains what EVMS is, why it is so desperately needed, and why it will very likely transform the way storage is managed on Linux systems. Have you ever stopped to think about how many powerful storage-related technologies are available for Linux? Consider just our options for a journaling filesystem: ReiserFS, ext3, XFS, and JFS. Several years ago, Linux didn't even have a journaling filesystem. Now, we have plenty of them and find ourselves in the luxurious position of being able to choose the best filesystem for our needs. Choice is definitely a good thing.
Now let's think beyond mere filesystems. Linux's software RAID capabilities, which have been around for awhile, present another set of possibilities to the Linux admin (for more information, see Resources for links to my two-part series on Linux software RAID). And recently, we've been blessed with Sistina's Linux LVM technology (logical volume management; see Resources for links to my two-part LVM series and to download Sistina). LVM allows admins to manage their storage resources with much greater flexibly than the traditional method of using static disk partitions. With LVM, admins can expand and shrink filesystems on running servers and take advantage of other amazing capabilities, such as filesystem snapshots.
The storage management problem
So, taken as a whole, Linux has a tremendously rich set of storage-related technologies. And therein lies the problem; taken as a whole, we do have some great tools. But try to use several of these storage technologies together and things become complicated. For example, let's imagine that we want to create a ReiserFS filesystem that sits upon an LVM logical volume (so that it can be dynamically expanded as needed), which in turn sits upon a RAID-1 software RAID volume (in order to provide some protection against disk failure).
To do this, we first add two new drives to our system, and then use fdisk to set up partitions on each drive. Next, we specify an /etc/raidtab file and use mkraid to enable our RAID-1 volume. Once we're done with that, we use pvcreate, vgcreate, and lvcreate to create an LVM logical volume out of our RAID-1 volume. Finally, we use mkreiserfs to create a filesystem on top of our new logical volume. After all that work, our new ReiserFS filesystem is ready for mounting.
Yes, we got the job done, but we had to use four separate types of tools to make it all happen, and our tools didn't have a consistent interface. As we continue to maintain our volume, we'll need to use both the software RAID and LVM tools as necessary. And none of the tools can see the "big picture" of how all the various layers are related, which, just in case you're wondering, is as follows:
We have two disks;
with one partition on each disk;
merged into a RAID-1 volume;
used to create an LVM physical volume;
added to an LVM volume group;
from which we created an LVM logical volume;
upon which we placed a ReiserFS filesystem.
The sheer number of tools involved (not to mention the fact that each one is oblivious to the others) is enough to discourage many administrators from trying to do anything so ambitious. And if a new admin were to inherit our craftily configured server, it would take quite a bit of detective work in order to even begin to understand how we configured everything. And if the new admin ever did figure it out (or even if we had documented it for him, as we should!), he might still dash out of the server room screaming in fear. Why? Because while Linux has oodles of storage-related technologies, the interfaces presented to the administrator for managing these technologies are certainly neither manageable nor consistent; this lack of consistency and unification makes sophisticated storage configurations darn spooky to implement and maintain.
Enter EVMS
If you suspect that I'm about to say that EVMS handily solves all of these problems in one fell swoop, then you're absolutely right. It does. EVMS provides a uniform, extensible, plug-in-based API for all storage technologies under Linux. What does that mean? It means that thanks to EVMS, you can use a single tool to partition disks, create LVM objects, and even create Linux software RAID volumes. And you can use the same tool to combine these technologies in powerful ways. EVMS can see the "big picture"; it can see exactly how everything is layered, from the filesystem all the way down to the physical disks holding the data. Not only that, but EVMS is compatible with all your existing Linux technologies. It doesn't force you to replace your partitions, LVM, or software RAID volumes. Instead, it will gladly work and interact with your existing storage configuration via its unified storage management interface. In fact, EVMS currently offers your choice of a command-line interface, an ncurses-based interface, and a fantastic storage management GUI written in GTK+. To whet your appetite, I'll show you a couple of screenshots of the GTK+ EVMS Administration Utility (from version 1.0.0) in action. In Figure 1, you can see that the lvm/vg1/swap region consists of data that originates from the hda2 segment, which lies on the hda disk.
Figure 1. The Regions tab of the GTK+ EVMS Administration Utility
Figure 2 shows a snapshot of a root volume. The snapshot data is coming from our lvm/vg1/root region. The root snapshot will remain static even as files are added and removed from the root filesystem.
Figure 2. The Volumes tab of the GTK+ EVMS Administration Utility
While EVMS is compatible with your existing storage arrangement, it also offers new, heretofore unavailable capabilities. One such capability in the 1.0.1 release is the EVMS snapshot feature. You may be familiar with snapshotting from Linux LVM; using snapshots, you can create an unchanging "view" of an existing filesystem, which comes in handy for backups. While EVMS supports LVM snapshots, its own exclusive snapshot capability is much more powerful, since you can snapshot any type of volume, even a standard Linux partition! In addition, EVMS snapshotting allows you to create a read/write snapshot -- essentially a "branch" of your existing filesystem. The EVMS developers are currently working on adding asynchronous snapshot support (for fast, temporary snapshots) and "rollback" support, which will throw away any changes made to the underlying volume since the creation of the snapshot if the administrator so wishes.
Now that you understand the need for EVMS and have a basic understanding of what it can do, let's take a look at what's involved in getting EVMS up and running.
Installing EVMS
EVMS consists of a set of kernel patches and userspace tools. To get EVMS up and running, we'll grab the EVMS source archive, unpack it, and use the included kernel patches to patch a kernel source tree. Then, we'll build the EVMS userspace tools. To complete the installation, we'll configure, build, and reboot with an EVMS-enabled kernel; after the system reboots, EVMS will be ready for use.
If you're looking for an easy way to begin exploring EVMS, consider downloading a Gentoo Linux Game mini-CD (see Resources for a link). In addition to allowing you to play an OpenGL-accelerated lightcycle game on systems with NVIDIA cards, our Games mini-CDs also boot into a runtime version of Gentoo Linux that includes full EVMS support. The official 1.4 release of Gentoo Linux (not yet released at the time this article was written) will include full EVMS support as well. Our Game/Install mini-CDs and our official Gentoo Linux 1.4 CDs will allow you to install Linux with your root filesystem on an EVMS volume.
Our first step is head over to the home of the
EVMS project. Under the "Latest file releases" section of the page, you should see an entry for the most recent version of EVMS. Clicking on the "download" link will take you to the main download page. I'll be stepping you through the process of installing EVMS version 1.0.1 from source, so select the evms-1.0.1.targz file (or equivalent) for download. After selecting your preferred download mirror, the download should begin. Once you have the archive, unpack it into a temporary directory:
# cd /tmp
# tar xzvf /path/to/evms-1.0.1.tar.gz
This archive contains the EVMS userspace tools as well as patches that we need to apply to a kernel source tree. In order for the EVMS userspace tools to compile correctly, we need to install the patches first. To see what kernels your release of EVMS supports, change directories as follows and type ls:
Listing 1. EVMS directory listing
# cd evms-1.0.1/kernel
# ls
evms-1.0.1-linux-2.4.patch evms-linux-2.4.7-common-files.patch
evms-1.0.1-linux-2.5.patch evms-linux-2.4.9-common-files.patch
evms-linux-2.4.10-common-files.patch evms-linux-2.5.1-common-files.patch
evms-linux-2.4.12-common-files.patch evms-linux-2.5.2-common-files.patch
evms-linux-2.4.13-common-files.patch evms-linux-2.5.3-common-files.patch
evms-linux-2.4.14-common-files.patch evms-linux-2.5.4-common-files.patch
evms-linux-2.4.16-common-files.patch evms-linux-2.5.5-common-files.patch
evms-linux-2.4.17-common-files.patch lilo-22.2-evms.patch
evms-linux-2.4.18-common-files.patch linux-2.4.12-VFS-lock.patch
evms-linux-2.4.4-common-files.patch linux-2.4.18-VFS-lock.patch
evms-linux-2.4.5-common-files.patch linux-2.4.4-VFS-lock.patch
evms-linux-2.4.6-common-files.patch linux-2.4.9-VFS-lock.patch
|
In this directory listing, we can see that this version of EVMS supports most kernels from 2.4.10 to 2.4.18, as well as 2.5.1 through 2.5.5. That means that in order to create an EVMS-enabled kernel, we should apply these patches against a stock kernel source tree that we download from kernel.org. Of these selections, choosing to apply EVMS to a 2.4.18 source tree would be the best choice, since it is the most recent, stable (2.4) version of the kernel currently supported at the time of this writing. If you don't have a recent stable kernel source archive like linux-2.4.18.tar.gz or .tar.bz2 archive handy, you'll need to download one (see Resources for a link). Now, we'll unpack our new kernel source tree in /usr/src and apply the appropriate EVMS patches:
Listing 2. EVMS patches
# cd /usr/src
if /usr/src/linux is a symbolic link, type:
# rm linux
otherwise, do this:
# mv linux linux.old
# tar xzvf /path/to/linux-2.4.18.tar.gz
# mv linux linux-2.4.18-evms
# ln -s linux-2.4.18-evms linux
|
You'll now have your to-be-patched source tree in /usr/src/linux-2.4.18-evms, with your /usr/src/linux symlink pointing to it. Now we're ready to start applying the EVMS patches. First, we'll apply the evms-1.0.1-linux-2.4.patch; this patch contains new EVMS-related files and will work with any 2.4.x kernel source tree:
# cd linux
# patch p1 < /tmp/evms-1.0.1/kernel/evms-1.0.1-linux-2.4.patch
Next, we'll apply the EVMS patch specific to our particular kernel version. This patch modifies existing files in the Linux kernel source tree, so it will likely have problems if you apply it to a kernel other than the one that it's designed to patch against:
# patch -p1 < /tmp/evms-1.0.1/kernel/evms-linux-2.4.18-common-files.patch
Now, check and see if there is a VFS-lock patch available for your particular kernel version. If there is, it would be good to apply it, as it will help EVMS get snapshots into a consistent state more easily:
# patch -p1 < /tmp/evms-1.0.1/kernel/linux-2.4.18-VFS-lock.patch
If you used an appropriate stock kernel for your patching as I recommended, then all the patches should have applied cleanly without any "rejects". To make sure, scan your patched kernel source tree for '.rej' files:
# find -name '*.rej'
If any .rej files exist, this means that one of the patches didn't apply correctly and requires manual fixing. Typically, you'll only see rejects if you decided to be a wise guy and apply the EVMS patches against an -ac (or some other) non-stock kernel; in that case, I'll assume that you know what you're doing and can fix the rejects for yourself :). Personally, I'm using an -ac-based kernel with the EVMS patch; there weren't many rejects, but the few rejects and compilation problems that I did experience were a bit tricky to figure out and fix. Should you run into problems, you can post a message to the EVMS list or visit the #evms channel on IRC (see Resources for links to these).
Now, let's configure our new kernel. Fire up make menuconfig or make xconfig and configure your kernel the way you like it. Then, ensure that any "Multi-device support (RAID and LVM)" options are disabled, since EVMS includes support for LVM and RAID internally. Then, head over to the "Enterprise Volume Management System" and enable all options so that they will compile directly into the kernel:
Listing 3. EVMS Kernel configuration
<*> EVMS Kernel Runtime
<*> EVMS Local Device Manager Plugin
<*> EVMS DOS Partition Manager Plugin
<*> EVMS SnapShot Feature
<*> EVMS DriveLink Feature
<*> EVMS Bad Block Relocation (BBR) Feature
<*> EVMS Linux LVM Package
<*> EVMS Linux MD Package
<*> EVMS MD Linear (append) mode
<*> EVMS MD RAID-0 (stripe) mode
<*> EVMS MD RAID-1 (mirroring) mode
<*> EVMS MD RAID-4/RAID-5 mode
<*> EVMS AIX LVM Package
<*> EVMS OS/2 LVM Package
<*> EVMS Clustering Package
(Default) EVMS Debug Level
|
Once you're done, save your configuration and then perform your standard kernel building/installation steps. But don't reboot just yet -- first, let's compile and install the EVMS userspace tools:
Listing 4. Compile and install the EVMS userspace tools
# cd /tmp/evms-1.0.1/engine
# ./configure --prefix=/usr --libdir=/lib --sbindir=/sbin
# --includedir=/usr/include --with-kernel=/usr/src/linux
# make
# make install
# ldconfig
|
Now our userspace EVMS tools are installed, and we have a new EVMS-enabled kernel that's ready for use. Go ahead and reboot; when your system comes back up, EVMS will be enabled. Unfortunately, actually showing you how to use EVMS will need to wait until my next article. But, if you're impatient (who isn't) and want to see some EVMS goodness, type evmsgui as root, which should pop up the GTK+ EVMS Administration Utility GUI.
One word of warning -- while the EVMS Administration Utility will not apply any changes you make unless you select the "Commitchanges" menu item, be careful. Despite the user-friendliness of the GTK+ interface, EVMS is a sophisticated system; it will take a bit of time to get up to speed on EVMS terminology and usage. Of course, if you wait until my next article to start playing, I'll guide you through this learning process. See you then!
Resources
About the author | | |
Residing in Albuquerque, New Mexico, Daniel Robbins is the Chief Architect of Gentoo Linux, an advanced ports-based Linux for x86, PowerPC, Sparc, and Sparc64 systems. He has also served as a contributing author for several books, including Samba Unleashed and SuSE Linux Unleashed. Daniel enjoys spending time with his wife, Mary, and his daughter, Hadassah. You can contact Daniel at drobbins@gentoo.org.
|
Rate this page
| |
