LVM, Demystified

I've been a sysadmin for a long time, and part of being a sysadmin is doing more than is humanly possible. Sometimes that means writing wicked cool scripts, sometimes it means working late, and sometimes it means learning to say no. Unfortunately, it also sometimes means cutting corners. I confess, I've been "that guy" more than once. A good example is SELinux. On more than a few (hundred!) occasions, I've simply disabled SELinux, because getting things to work right is often really frustrating and time consuming. The same is true with LVM (Logical Volume Manager). I didn't get it. I thought it added an unnecessary layer of complexity. I thought it meant another potential point of failure. I thought it was stupid.

I was wrong.

LVM is an incredibly flexible, ridiculously useful and not terribly complicated to use system. It makes life easier. It makes future storage upgrades and migrations simple. Quite simply, I love it. So in this article, I cover the concepts and usage of LVM. By the time I'm done, hopefully you'll love it as much as I do!

What LVM Is

The best analogy I can come up with for explaining LVM is a SAN. If you've ever used a SAN (Storage Area Network) in your server environment, you know it abstracts the idea of individual hard drives and allows you to carve out "chunks" of space to use as drives. Rather than worrying about how big your hard drives might be, a SAN lets you throw all your hard drives into a big chassis and then allocate space to individual clients without being concerned about how many or how few physical drives are being used. LVM is sort of like that, but for an individual system rather than an entire network.

Figure 1 shows my poor attempt at drawing the concept of an LVM system. At first glance, it might seem like using an LVM is silly. Why combine a bunch of drives together, only to carve them up into virtual drives, right? Thankfully, that simple concept gives incredible flexibility down the road. Need a great big partition, but have only a bunch of smaller disks? No problem. Have only a couple disks now, but want to add more later without reformatting? No problem. Need to take snapshots, like with virtual servers, but you're using actual bare metal? No problem. LVM makes dealing with storage far better than partitioning drives or using a simple RAID setup (which, incidentally, brings me to the next issue).

Figure 1. It's important to think of my drawings as art—possibly second-grade art.

What LVM Isn't

With all the flexibility and expandability I mentioned in the previous paragraph, it seems like LVM would be a perfect replacement for hardware- or software-based RAID. After all, one of the big advantages of RAID is that multiple smaller drives can be used as a single, larger drive. For that particular feature, LVM is indeed ideal. Unfortunately, however, LVM doesn't provide any options for redundancy or parity. That means if you have a drive fail in LVM, you lose data. There's no such thing as striped LVM or mirrored LVM; it's simply not designed to do that.

LVM also isn't designed to increase speed by striping reads and writes across multiple disks. As block devices in the volume group fill up, such simultaneous read/writes may occur, but it's not by design and certainly not to gain speed. Hopefully, it's clear: LVM is really cool, but it is not in any way a replacement for RAID. Thankfully, it doesn't need to be.

(Note: recent versions of LVM actually do provide striping and mirroring features. In some cases, it can take the place of RAID completely. I still think understanding them as separate concepts is important. If you want to learn more about LVM and utilize the RAID features, I'll leave that as an exercise for you.)


Shawn is Associate Editor here at Linux Journal, and has been around Linux since the beginning. He has a passion for open source, and he loves to teach. He also drinks too much coffee, which often shows in his writing.