A Linux LVM Perspective

A while ago I purchased an 18Gb SCSI hard drive to replace the aging, and full, 4Gb IDE drive on my Mandrake Linux box at home. Since the drive was much larger than I needed at the time, I wasn't sure how to partition it up; this, coupled with the fact that I'm leery of large partitions, made me decide to use Logical Volume Management (LVM) on it.

I'm not going to go into great detail about the installation; suffice it to say that I didn't have any trouble getting the system installed. I did, however, read the LVM HOWTO thoroughly and made sure I had a good idea of what was going on before I attempted the install. The the HOWTOs could have had more information and examples in them. In particular, I had to discover that I had to add:

action "Locating LVM shares" vgscan
action "Activating LVM shares" vgchange -ay

to the /etc/rc.sysinit file, or my LVM partitions wouldn't be mountable. Other than this, it was pretty painless.

For the sake of this article, I'll define a couple of words and concepts. LVM works by adding layers under the filesystem. You start with a Physical Volume (PV), which can be hard drives, or partitions on a hard drive, or whatever. Then you add the PV to a Group, so a Group is made up of several PVs. Then you can break a group up into Logical Volumes (LVs). These are the things you end up putting a filesystem on and using. I only have one Group on my computer, which contains all of my PVs and is broken up into LVs. I'm not sure why you'd have more than one Group, but I'm sure there's a use for multiple Groups. Anyway, the sum of your PVs is how much space a Group has, and you can divide this up amongst your LVs as you want. You don't have to use all of the space, and you can add or subtract space from your LVs on the fly. If you need to add space to your Group, you can add more PVs. Actually, once you add the PVs to the Group, you don't worry about them; LVM takes care of allocating space out of the pool.

The basic procedure is (and this is pretty much straight out of the LVM-HOWTO):

Please note that I am not using striped LVs. If you are, you probably don't want to use more than one partition on a disk.

In any case, I partitioned the drive up into 2Gb partitions, except for the very first partition and a swap space. I didn't include the first partition in the LVM, because I didn't know how the kernel would handle LVMs at boot time. I still think that this is a good idea, until LVM support is more standard in distributions. I found the whole process rather painless, although it was made easier by the fact that I could still boot from the IDE drive while I was testing it. I ended up allocating 11Gb of the total drive to virtual partitions, leaving 7Gb untouched.

Why would you want to do this? The first is that LVs are dynamic. If one partition grows beyond what you expected it to be, you can increase its size from your Group pool. If one partition ends up being too large, you can reduce its size and add the space to your Group pool. If your Group runs out of space, you can add a hard drive and assign its space to your Group pool. Finally, partitioning your hard drive into smaller segments is a safety net; if one of the partitions gets corrupted, at least you don't lose the information on the other partitions. Note that I haven't tested this last part myself, and being able to recover that information largely depends on how well your filesystem handles having a large chunk taken out of the middle. Still, the theory is good.

I've been pretty happy with the system. Really, having LVMs on my machine has been transparant. a good sign that the system functions well. In fact, the most difficulty has been that, when it came time to access the LVM fuctions again, it had been so long since I'd done anything with it that I had forgotton the commands to use! I'm running ReiserFS on all of the LVs; I've been using ReiserFS for a long while now, and it is good to see that there are no conflicts between the two technologies.

Basic usage proved to be stable: LVM worked just as well for me as using HD partitions directly. The big test came when I ran out of space on one of the partitions, and had to use the LVM features.

I had just installed a 200Mb package -- "Acorn", just to support the Linux OpenSource game developers, of course -- on /usr, which dropped the size of the logical volume down to 50Mb. Time to put LVM test, and expand an LV. I had this program called lvmgui, a java interface to the LVM utilities which I had installed when I first set up LVM on the computer, so I ran it to see much extra space I had in the group (I'd forgotten). lvmgui is a great program; I highly recommend it. It gives you a decent overview, and it allows you do most, if not all, of the things you can do from the command line. Increasing the size of /usr was as easy as selecting the LV in the tree, clicking the "extend" button, entering the amount to increase the size by (500Mb in my case), and clicking "go". It was boringly simple. You can also decrease the size of the volumes. From what I understand, if a HD partition goes bad, you can remove it from the logical volume, and still get to the rest of the stuff in the volume. You have to resize the file system as well, but this too was simple: resize_reiserfs -s+500M -fv /dev/group1/usr. I did all of this without unmounting the partition, and it took about five minutes.

If you want to do the resize by hand, the command is lvextend -L+<size-in-MB> <lv>; for example, I could have resized /usr with lvextend -L+500 /dev/group1/usr.

I hereby proclaim LVM a success, and recommend that you start using it whenever you're installing a new system. It isn't something you'd use initially, but it is really nice to have when you need it.