What are the benefits of the Logical Volume Manager [closed]

Question

What are the features and potential benefits of Logical Volume Manager beyond what is detailed on its Wikipedia page?

Answer 1

Taken directly from my blog entry: http://www.standalone-sysadmin.com/blog/2008/09/introduction-to-lvm-in-linux/

First off, lets discuss life without LVM. Back in the bad old days, you had a hard drive. This hard drive could have partitions. You could install file systems on these partitions, and then use those filesystems. Uphill both ways. It looked a lot like this:

You've got the actual drive, in this case sda. On that drive are two partitions, sda1 and sda2. There is also some unused free space. Each of the partitions has a filesystem on it, which is mounted. The actual filesystem type is arbitrary. You could call it ext3, reiserfs, or what have you. The important thing to note is that there is a direct one-to-one corrolation between disk partitions and possible file systems.

Lets add some logical volume management that recreates the exact same structure:

Now, you see the same partitions, however there is a layer above the partitions called a "Volume Group", literally a group of volumes, in this case disk partitions. It might be acceptible to think of this as a sort of virtual disk that you can partition up. Since we're matching our previous configuration exactly, you don't get to see the strengths of the system yet. You might notice that above the volume group, we have created logical volumes, which might be thought of as virtual partitions, and it is upon these that we build our file systems.

Lets see what happens when we add more than one physical volume:

Here we have three physical disks, sda, sdb, and sdc. Each of the first two disks has one partition taking up the entire space. The last, sdc, has one partition taking up half of the disk, with half remaining unpartitioned free space.

We can see the volume group above that which includes all of the currently available volumes. Here lies one of the biggest selling points. You can build a logical partition as big as the sum of your disks. In many ways, this is similar to how RAID level 0 works, except there's no striping at all. Data is written for the most part linearly. If you need redundancy or the performance increases that RAID provides, make sure to put your logical volumes on top of the RAID arrays. RAID slices work exactly like physical disks here.

Now, we have this volume group which takes up 2 and 1/2 disks. It has been carved into two logical volumes, the first of which is larger than any one of the disks. The logical volumes don't care how big the actual physical disks are, since all they see is that they're carved out of myVolumeGroup01. This layer of abstraction is important, as we shall see.

What happens if we decide that we need the unused space, because we've added more users?

Normally we'd be in for some grief if we used the one to one mapping, but with logical volumes, here's what we can do:

Here we've taken the previously free space on /dev/sdc and created /dev/sdc2. Then we added that to the list of volumes that comprise myVolumeGroup01. Once that was done, we were free to expand either of the logical volumes as necessary. Since we added users, we grew myLogicalVolume2. At that point, as long as the filesystem /home supported it, we were free to grow it to fill the extra space. All because we abstracted our storage from the physical disks that it lives on.

Alright, that covers the basic why of Logical Volume Management. Since I'm sure you're itching to learn more about how to prepare and build your own systems, here are some excellent resources to get you started:

http://www.pma.caltech.edu/~laurence/Linux/lvm.html
http://www.freeos.com/articles/3921/
http://www.linuxdevcenter.com/pub/a/linux/2006/04/27/managing-disk-space-with-lvm.html

Answer 2

You can use LVM to do a lot of things with disks. The main benefit is the ability to grow filesystems on the fly. Suppose you are setting up a log server, and you know in the future you'll have a ton of data. Ext3 supports a maximum of 16TB (more depending on your kernel and version of EL). But what if you know in 2 years you'll need 1PB of storage? Well, this creates some problems. First, your boss will look at you with deer in headlights eyes when you tell him the price of that storage hardware. This leads to another problem - you need to start with a small solution that you can scale upwards. LVM gives you that option. You start with a few disks. Then you add more, turn them into a logical group, add them to the first logical volume, increase the size of the volume, and finally grow the filesystem. Voila, you've got a nice scaling filesystem.

This saves you from having to move the data off of the device, reformat the LUN's, and then moving everything back to perform an upgrade. Sorry for the brevity, hope that makes sense.

Edit: I should also note that if you're dealing with 1PB, you're not going to want to use Ext3... probably XFS.

Answer 3

There are a number of indirect benefits of LVM. The main thing LVM does is abstract the physical disks away from the operating system. The main benefit of this is simply flexibility. Most of the benefits of LVM are only realised when you have a filesystem that supports being resized on the fly. The basic thing LVM does is described below:

System Partitions exist one layer above the disk

Without LVM, Linux uses the partitions located physically on the disk. The partitions are direct device names. The partition table resides in the MBR and normally (in the case of logical extended partitions) in the extended boot record (which allows you to create a larger number of partitions). Partitions define a size and type among other attributes (more specifically, they define a start and end cylinder which essentially defines the size). Because they are so closely tied to the disk, setting up a "correct" partitioning scheme upon install is important. If suddenly, a machine function changes or if you're a novice and you've not understood the implications of partitioning, or if you're underestimated disk usage somewhere, or logs of a particular application, changing that partitioning can be cumbersome. There are tools for doing it, but you generally need to move data off the partition to change it. Obviously, if you've got four partitions, changing the second partition end cylinder effects the third and fourth partitions start cylinders and so you get into a messy situation.

The naive may advocate the use of a single large partition, but you may become undone when you need to introduce quotas, or isolate rogue processes filling up parts of your system (e.g. /var/log, /tmp etc.)

The benefits of this are:

Adding/removing storage

Adding storage is generally trivial. If you're using hardware or software RAID and you add more disks, you may often have to fiddle around with symlinks to rebuild the RAID array in order to have Linux make your new storage available in the locations you want.

Take the example of a large /home directory which is getting full. That exists on an existing two disk RAID 1 volume. You want to add two more disks. You set those up in a hardware RAID 1 configuration. Without LVM, you have a couple of options:

1. Rebuild the full raid array in a 1+0 configuration which requires moving data off the machine, rebuilding and moving it back on.
2. Create a new RAID 1 volume group which is separate. Linux already has the first RAID volume mounted on /home, so you need to mount the second RAID volume on /home1 or similar. Now to get the appropiate paths for users that are consistent with the first, you may need to use symlinks to get the same effect. In addition this solution requires constant maintenance of the original RAID volume and potentially migrating data off the original partition.

With LVM, you can simply add the new RAID 1 volume group to the additional pool of storage, resize the filesystem (providing it supports it) and voila, /home is now suddenly larger. You don't need to symlink anything or do maintenance on potentially moving data from /home to /home1 or vice versa. Rinse, wash, repeat for future disk upgrades.

Online maintenance

Most LVM tasks, providing the hardware supports it, can be done online, without rebooting the machine. If you can hot swap disks on a system, you can add new disks and subsequently remove old (maybe smaller) disks to increase system storage requirements.

One of the main issues with LVM volumes is as they approach capacity, fragmentation can become an issue in my experience. Volumes >90%, and really >95% can mean you can end up with bad fragmentation on disk depending on your disk usage and file types. It's rarely something to overly concern yourself about, that's the case with any kind of volume / partition management, but it's fragmentation on the volume layer as opposed to on the partition that's the concern here.

Answer 4

You should have provided more info about the situation you are going to apply this in, that way we can give targeted answers rather than broad possibly unrelated answers (I can't comment else I would've said this in a comment).

Now onto the question itself, you have easy creation, resizing and deletion of volumes (aka partitions), and another nice feature (depending on your situation) is the ability to create snapshots of a volume.

Answer 5

Even though you are already selected best answer I'd like to contribute my opinion to this topic. From my experience I would question usefulness of LVM if you have one physical drive or even if you have several drives (I personally never use LVM on system drive). However, where LVM really indispensable is on top of hardware RAID. This allows to clearly separate functions of RAID and LVM - you use RAID to manage reliability and performance characteristics of your storage and you use LVM to allocate actual volumes to the system. Sometimes, this functionality overlaps, i.e. LVM can provide functionality of RAID-0 and RAID-1 but I wouldn't recommend using any of the two with any serious build.

Basically RAID and LVM belong together, using one without the other is usually suboptimal.