LVM in detail
Neil Bothwick demonstrates how to take advantage of the power of LVM to make the most of your hard drives and partitions.
Neil Bothwick gives you the power of a super hero (cape not included) to take full control of your drives and partitions.
Back when hard drives were small and expensive, partition management was not much of an issue. Once you had your root, swap and home partitions in place, there wasn’t much space left for anything else, and multiple drives were a luxury. Now that hard drives are so large, fast and cheap, we need a better way to organise things. Yes, you could just have root and swap and dump everything on the root partition but there are many advantages to separate filesystems.
So called ‘next generation’ filesystems [ seeRoundup, LXF203] such as Btrfs and ZFS will handle everything for you, including RAID, volume management, snapshots and much more. But what if you want to stick with a tried and tested filesystem such as ext4, or need the large file speed of XFS, but still want to work with multiple drives and partitions? You need Logical Volume Manager (LVM). If you run Fedora, you probably already use LVM, so here we will show you how it all fits together and how to get the best out of it.
The core of LVM
There are three core components to LVM:
Physical Volumes (PVs) These are the physical block devices used as the building blocks. They are usually disk partitions, but could be dm-crypt devices for an encrypted setup or virtual disk files if you want to experiment with LVM or even whole disks or any combination of these.
Volume Groups (VGs) A volume group consists of one or more physical volumes and can be thought of as the LVM equivalent of a disk drive, a sort of virtualised disk. Physical volumes can be added to (or removed from) a volume group to alter its size.
Logical Volumes (LVs) These are the devices on which you create filesystems. You can think of them as partitions on the volume group, but they neither have the physical boundaries of a hard disk partition, nor the limitations associated with them.
Let’s start with a simple example, using one PV. In these examples we will assume /dev/sdb1 is a partition on an external device. ( Don’tplaywithyoursystemdriveatthis pointbutseetheATestingSetupbox,p73forotheroptions.) If this partition already contains a filesystem, it will be overwritten. All commands should be run at root or prefixed with sudo . Start with $ pvcreate /dev/sdb1 . This will simply initialises the partition ready for use. Now we create a volume group containing it with: $ vgcreate MyFirstVG /dev/sdb1.
Give the VG a meaningful name, maybe containing the hostname of the computer, don’t use something like VG00. If you later connect this disk to another computer that has a VG with the same name you will discover why unique names are important. The next step is to create a logical volume and put a filesystem on it: $ lvcreate --size 1G --name TestLV MyFirstVG $ mkfs.ext4 /dev/MyFirstVG/TestLV
You can see from the second command that your volume groups appear as directories under /dev containing entries for each logical volume, you’ll also find them all at /dev/ mapper/vgname-lvname. Once you‘ve created a logical volume, you can do anything you would normally do with a partition with it, such as creating a filesystem and mounting it, but there is more that’s possible.
For a start, you no longer have any form of partition limit, you can create as many LVs as you want, making it easy to organise your hard drives. Worried about all those ISO images you are downloading filling your home directory? Create a separate LV for them; it will only fill itself and not cause booting problems by filling up more important filesystems (try logging in when /home or /var is at 100%). You can also freely add, remove and resize logical volumes, doing so with partitions means much shuffling of data, extended GParted operations and usually a reboot. Because of this, it’s important to learn a different mindset when organising your disk. Don’t think about all of the available space, only about what you need. Make a logical volume large enough to handle the expected needs plus enough headroom to avoid fragmentation. Generally it’s a good idea to stay below 80% full when possible, so making the filesystem say 50% larger than you will use should give plenty of wiggle room. Why not make it larger? Because you don’t need to and may need the space for something else later should your usage patterns change. You also don’t need to because enlarging a logical volume and the partition it contains is dead simple, the
opposite is far from true. The golden rule of resizing filesystems: enlarging is much, much easier than reducing. To increase the size of the above test volume to 2G is as simple as: $ lvresize --size 2G MyFirstVG/TestLV or $ lvresize --size +1G MyFirstVG/TestLV followed by $ resize2fs /dev/MyFirst/VG/TestLV
This can be done with the filesystem not only mounted but in use too. Reducing the size is a lot more work, and time, as it involves first unmounting the filesystem, then reducing with resize2fs , which often requires an fsck , then using lvresize to reduce the size of the LV and finally running
resize2fs again to make the filesystem fill the LV, as you should reduce the filesystem by a bit extra to make sure you don’t lose any of it when reducing the LV. If this contains system directories, you may have to use a live CD. $ umount /dev/MyFirst/VG/TestLV $ fsck -f /dev/MyFirst/VG/TestLV $ resize2fs /dev/MyFirst/VG/TestLV 950M $ lvresize --size 1G MyFirst/VG/TestLV $ resize2fs /dev/MyFirst/VG/TestLV
Multiple drives
What happens when you start to run out of disk space? You can only go so far with resizing things, once the volume group is full – so where do you go next? On a desktop or server system, that answer is quite simple: add another hard drive and call it /dev/sdc: $ pvcreate /dev/sdc1 $ vgextend MyFirstVG /dev/sdc1
That’s all there is to it, your volume group now has lots more free space and you can enlarge or add logical volumes as you need. Speaking of free space, how do you know just how much free space you have in your VG and what is using the rest of it? To see the details for your VG run $ vgdisplay MyFirstVG .
If you omit the name of the VG it will show data for all of them. If you only want to see how much space is being used and free, the short output from vgs may be more suitable. There are equivalent commands pvdisplay , pvs , lvdisplay and lvs for physical and logical volumes. Each of these commands lists all relevant objects unless you give it a list of those you want to see.
We have seen how easy it is to add a new device, but removing one is slightly more work, but not much. Say you added /dev/sdc1, a much larger disk, and now want to retire
/dev/sdb, maybe because it is older and slower. First, you move all the data from the old disk to the new one: $ pvmove
/dev/sdb1 . This will move all data from the specified PV to others in the volume group – you can specify which ones, if there are many, but this is usually unnecessary unless you intend to remove more than one. Now remove the PV from the volume group with vgreduce using vgreduce MyFirstVG /dev/sdb1 or vgreduce MyFirstVG --all . The second option removes all unused physical volumes. Many distro installers now have an option to use LVM when setting up your disk – Fedora has done it by default for some years. If you want to boot a system with the root filesystem on LVM, you will need to use an initramfs, but your distro’s installer will take care of that. If you are setting things up yourself, Dracut [ seeTutorials,p78, LXF197], will create an initramfs that boots from LVM. There is plenty more to LVM, as evidenced by the multiple man pages, but we have covered enough for you to be able to use and understand it.