LVM Building Blocks

Logical Volume Management utilizes the kernel's device-mapper feature to provide a system of partitions independent of underlying disk layout. With LVM you abstract your storage and have "virtual partitions", making extending/shrinking easier (subject to potential filesystem limitations).

Virtual partitions allow addition and removal without worry of whether you have enough contiguous space on a particular disk, getting caught up fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way.

Advantages

LVM gives you more flexibility than just using normal hard drive partitions:

Use any number of disks as one big disk.

Have logical volumes stretched over several disks.

Create small logical volumes and resize them "dynamically" as they get filled up.

Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.

Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.

Online/live migration of LV being used by services to different disks without having to restart services.

Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.

Support for various device-mapper targets, including transparent filesystem encryption and caching of frequently used data. This allows creating a system with (one or more) physical disks (encrypted with LUKS) and LVM on top to allow for easy resizing and management of separate volumes (e.g. for /, /home, /backup, etc.) without the hassle of entering a key multiple times on boot.

Disadvantages

Additional steps in setting up the system, more complicated.

If dual-booting, note that Windows does not support LVM; you will be unable to access any LVM partitions from Windows.

Getting started

Installing Arch Linux on LVM

You should create your LVM Volumes between the partitioning and formatting steps of the installation procedure. Instead of directly formatting a partition to be your root file system, the file system will be created inside a logical volume (LV).

Create your physical volumes (PVs). If you have one disk it is best to just create one PV in one large partition. If you have multiple disks you can create partitions on each of them and create a PV on each partition.

Create partitions

If you use Master Boot Record partition table, set the partition type ID to 8e (partition type Linux LVM in fdisk).

If you use GUID Partition Table, set the partition type GUID to E6D6D379-F507-44C2-A23C-238F2A3DF928 (partition type Linux LVM in fdisk and 8e00 in gdisk).

Create physical volumes

To list all your devices capable of being used as a physical volume:

# lvmdiskscan

Warning: Make sure you target the correct device, or below commands will result in data loss!

Create a physical volume on them:

# pvcreate DEVICE

This command creates a header on each device so it can be used for LVM. As defined in #LVM Building Blocks, DEVICE can be a disk (e.g. /dev/sda), a partition (e.g. /dev/sda2) or a loop back device. For example:

Note: You can create more than one volume group if you need to, but then you will not have all your storage presented as one disk.

Create in one step

LVM allows you to combine the creation of a volume group and the physical volumes in one easy step. For example, to create the group VolGroup00 with the three devices mentioned above, you can run:

# vgcreate VolGroup00 /dev/sda2 /dev/sdb1 /dev/sdc

This command will first set up the three partitions as physical volumes (if necessary) and then create the volume group with the three volumes. The command will warn you it detects an existing filesystem on any of the devices.

Create logical volumes

Tip: If you wish to use snapshots, logical volume caching, thin provisioned logical volumes or RAID see #Logical volume types.

Now we need to create logical volumes on this volume group. You create a logical volume with the next command by giving the name of a new logical volume, its size, and the volume group it will live on:

# lvcreate -L <size> <volume_group> -n <logical_volume>

For example:

# lvcreate -L 10G VolGroup00 -n lvolhome

This will create a logical volume that you can access later with /dev/VolGroup00/lvolhome. Just like volume groups, you can use any name you want for your logical volume when creating it besides a few exceptions listed in lvm(8).

You can also specify one or more physical volumes to restrict where LVM allocates the data. For example, you may wish to create a logical volume for the root filesystem on your small SSD, and your home volume on a slower mechanical drive. Simply add the physical volume devices to the command line, for example:

# lvcreate -L 10G VolGroup00 -n lvolhome /dev/sdc1

If you want to fill all the free space left on a volume group, use the next command:

# lvcreate -l 100%FREE <volume_group> -n <logical_volume>

You can track created logical volumes with:

# lvdisplay

Note: You may need to load the device-mapper kernel module (modprobe dm_mod) for the above commands to succeed.

Tip: You can start out with relatively small logical volumes and expand them later if needed. For simplicity, leave some free space in the volume group so there is room for expansion.

Create file systems and mount logical volumes

Your logical volumes should now be located in /dev/YourVolumeGroupName/. If you cannot find them, use the next commands to bring up the module for creating device nodes and to make volume groups available:

# modprobe dm_mod
# vgscan
# vgchange -ay

Now you can create file systems on logical volumes and mount them as normal partitions (if you are installing Arch linux, refer to mounting the partitions for additional details):

Warning: When choosing mountpoints, just select your newly created logical volumes (use: /dev/Volgroup00/lvolhome). Do not select the actual partitions on which logical volumes were created (do not use: /dev/sda2).

Configure mkinitcpio

In case your root filesystem is on LVM, you will need to enable the appropriate mkinitcpio hooks, otherwise your system might not boot. Enable:

udev and lvm2 for the default busybox based initramfs

systemd and sd-lvm2 for systemd based initramfs

udev is there by default. Edit the file and insert lvm2 between block and filesystems like so:

The lvm2 and sd-lvm2 hooks are installed by lvm2, not mkinitcpio. If you are running mkinitcpio in an arch-chroot for a new installation, lvm2 must be installed inside the arch-chroot for mkinitcpio to find the lvm2 or sd-lvm2 hook. If lvm2 only exists outside the arch-chroot, mkinitcpio will output Error: Hook 'lvm2' cannot be found.

Indeed pvresize will refuse to shrink a PV if it has allocated extents after where its new end would be. One needs to run pvmove beforehand to relocate these elsewhere in the volume group if there is sufficient free space.

Move physical extents

Before moving free extents to the end of the volume, one must run pvdisplay -v -m to see physical segments. In the below example, there is one physical volume on /dev/sdd1, one volume group vg1 and one logical volume backup.

One can observe FREE space are split across the volume. To shrink the physical volume, we must first move all used segments to the beginning.

Here, the first free segment is from 0 to 153600 and leaves us with 153601 free extents. We can now move this segment number from the last physical extent to the first extent. The command will thus be:

this command moves 399668 - 307201 + 1 = 92468 PEs from the last segment to the first segment. This is possible as the first segment encloses 153600 free PEs, which can contain the 92467 - 0 + 1 = 92468 moved PEs.

the --alloc anywhere option is used as we move PEs inside the same partition. In case of different partitions, the command would look something like this:

# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999

this command may take a long time (one to two hours) in case of large volumes. It might be a good idea to run this command in a Tmux or GNU Screen session. Any unwanted stop of the process could be fatal.

once the operation is complete, run fsck to make sure your file system is valid.

Resize physical volume

Once all your free physical segments are on the last physical extents, run vgdisplay and see your free PE.

Then you can now run again the command:

# pvresize --setphysicalvolumesize sizePhysicalVolume

See the result:

# pvs

PV VG Fmt Attr PSize PFree
/dev/sdd1 vg1 lvm2 a-- 1t 500g

Resize partition

Logical volumes

Note:lvresize(8) provides more or less the same options as the specialized lvextend(8) and lvreduce(8) commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a -r/--resizefs option which allows to resize the file system together with the LV using fsadm(8) (ext2, ext3, ext4, ReiserFS and XFS supported). Therefore it may be easier to simply use lvresize for both operations and use --resizefs to simplify things a bit, except if you have specific needs or want full control over the process.

Warning: While enlarging a file system can often be done on-line (i.e. while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your FS supports what you are trying to do.

Snapshots

LVM allows you to take a snapshot of your system in a much more efficient way than a traditional backup. It does this efficiently by using a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system. Thus, you can snapshot a system with 35 GiB of data using just 2 GiB of free space so long as you modify less than 2 GiB (on both the original and snapshot). In order to be able to create snapshots you need to have unallocated space in your volume group. Snapshot like any other volume will take up space in the volume group. So, if you plan to use snapshots for backing up your root partition do not allocate 100% of your volume group for root logical volume.

Configuration

You create snapshot logical volumes just like normal ones.

# lvcreate --size 100M --snapshot --name snap01 /dev/vg0/lv

With that volume, you may modify less than 100 MiB of data, before the snapshot volume fills up.

Reverting the modified 'lv' logical volume to the state when the 'snap01' snapshot was taken can be done with

# lvconvert --merge /dev/vg0/snap01

In case the origin logical volume is active, merging will occur on the next reboot (merging can be done even from a LiveCD).

Note: The snapshot will no longer exist after merging.

Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.

The snapshot can be mounted and backed up with dd or tar. The size of the backup file done with dd will be the size of the files residing on the snapshot volume.
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.

Snapshots are primarily used to provide a frozen copy of a file system to make backups; a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.

LVM cache

The cache logical volume type uses a small and fast LV to improve the performance of a large and slow LV. It does this by storing the frequently used blocks on the faster LV. LVM refers to the small fast LV as a cache pool LV. The large slow LV is called the origin LV. Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. The cache data LV is where copies of data blocks are kept from the origin LV to increase speed. The cache metadata LV holds the accounting information that specifies where data blocks are stored (e.g. on the origin LV or on the cache data LV). Users should be familiar with these LVs if they wish to create the best and most robust cached logical volumes. All of these associated LVs must be in the same VG.

Create cache

The fast method is creating a PV (if necessary) on the fast disk and add it to the existing volume group:

# vgextend dataVG /dev/sdx

Create a cache pool with automatic meta data on sdb, and convert the existing logical volume (dataLV) to a cached volume, all in one step:

Obviously, if you want your cache to be bigger, you can change the -L parameter to a different size.

Note: Cachemode has two possible options:

writethrough ensures that any data written will be stored both in the cache pool LV and on the origin LV. The loss of a device associated with the cache pool LV in this case would not mean the loss of any data;

writeback ensures better performance, but at the cost of a higher risk of data loss in case the drive used for cache fails.

If a specific --cachemode is not indicated, the system will assume writethrough as default.

Remove cache

If you ever need to undo the one step creation operation above:

# lvconvert --uncache dataVG/dataLV

This commits any pending writes still in the cache back to the origin LV, then deletes the cache. Other options are available and described in lvmcache(7).

RAID

lvm(8) RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).

will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on /dev/sda2 and /dev/sdb2.

Configure mkinitcpio for RAID

If your root filesystem is on LVM RAID additionally to lvm2 or sd-lvm2 hooks, you need to add dm-raid and the appropriate RAID modules (e.g. raid0, raid1, raid10 and/or raid456) to the MODULES array in mkinitcpio.conf.

Graphical configuration

There is no "official" GUI tool for managing LVM volumes, but system-config-lvmAUR covers most of the common operations, and provides simple visualizations of volume state. It can automatically resize many file systems when resizing logical volumes.

Troubleshooting

Boot/Shutdown-problems because of disabled lvmetad

The factual accuracy of this article or section is disputed.

Reason: As of Linux 5, lvmetad is causing some slowdowns during boot and shutdown, but upstream has left it enabled. (Discuss in Talk:LVM#lvmetad and linux 5)

The use_lvmetad = 1must be set in /etc/lvm/lvm.conf. This is the default now - if you have a lvm.conf.pacnew file, you must merge this change.

LVM commands do not work

Load proper module:

# modprobe dm_mod

The dm_mod module should be automatically loaded. In case it does not, you can try:

The factual accuracy of this article or section is disputed.

Reason: Should module loading at boot be done using "/etc/modules-load.d" instead? (Discuss in Talk:LVM#)

Logical Volumes do not show up

If you are trying to mount existing logical volumes, but they do not show up in lvscan, you can use the following commands to activate them:

# vgscan
# vgchange -ay

LVM on removable media

Symptoms:

# vgscan

Reading all physical volumes. This may take a while...
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error
Found volume group "backupdrive1" using metadata type lvm2
Found volume group "networkdrive" using metadata type lvm2

Cause:

Removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:

# vgchange -an volume group name

Fix: assuming you already tried to activate the volume group with vgchange -ay vg, and are receiving the Input/output errors:

# vgchange -an volume group name

Unplug the external drive and wait a few minutes:

# vgscan
# vgchange -ay volume group name

Resizing a contiguous logical volume fails

The reason is that the logical volume was created with an explicit contiguous allocation policy (options -C y or --alloc contiguous) and no further adjacent contiguous extents are available (see also reference).

To fix this, prior to extending the logical volume, change its allocation policy with lvchange --alloc inherit <logical_volume>. If you need to keep the contiguous allocation policy, an alternative approach is to move the volume to a disk area with sufficient free extents (see [1]).

Command "grub-mkconfig" reports "unknown filesystem" errors

Thinly-provisioned root volume device times out

With a large number of snapshots, thin_check runs for a long enough time so that waiting for the root device times out. To compensate, add the rootdelay=60 kernel boot parameter to your boot loader configuration. Or, make thin_check skip checking block mappings (see [2]) and regenerate the initramfs: