LVM in Linux: Physical Volumes, Groups and Logical Volumes in Practice

LVM (Logical Volume Manager) is the logical volume manager in Linux that separates filesystems from physical disks. Instead of rigidly tying /var to the partition /dev/sdb1, you put disks into a common pool and carve out volumes of the size you need. When space runs short, a volume grows with one command, without a reboot and without stopping the service. Below we go through how LVM works in Linux, how to create volumes from scratch, extend them, take a snapshot, and avoid losing data on typical mistakes.

Why LVM is needed when there are ordinary partitions

An ordinary partition is a continuous piece of a single disk. Its size is set when the disk is partitioned, and it can be enlarged only if there is free space right after it. When the disk is full, you have to buy a new one, move the data and rewrite /etc/fstab, and stop the service for that time.

LVM solves three tasks:

• Flexible size. A logical volume can be grown (and for ext4 also shrunk) at any time.
• Combining disks. Several physical disks become one pool; a single volume can sit on two disks at once.
• Snapshots. An instant copy of a volume before an update, a database migration or another risky operation.

That is why the installers of Ubuntu Server, RHEL, Rocky and AlmaLinux offer LVM by default, and on data servers it is almost always used.

The three levels of LVM: PV, VG and LV

The whole logic of LVM fits into three concepts. A handy analogy: the disks are sacks of flour, the group is a shared warehouse, and the logical volumes are the portions you weigh out from the warehouse.

Inside a VG the space is divided into extents (PE, physical extents) — blocks of fixed size, 4 MiB by default. A logical volume is simply a set of extents that do not have to be contiguous and can lie on different disks. That is exactly why a volume is so easy to extend: LVM appends free extents to it from anywhere.

The device of a logical volume is available under two equivalent paths: /dev/data_vg/app and /dev/mapper/data_vg-app. Under the hood it is a kernel device-mapper device.

How to see what already exists

First make sure the package is installed: on Debian and Ubuntu it is lvm2 (sudo apt install lvm2), and in the RHEL family it is installed by default. For an overview there are short and detailed commands:

$ sudo pvs
  PV         VG      Fmt  Attr PSize   PFree
  /dev/sdb   data_vg lvm2 a--  <20.00g      0
  /dev/sdc   data_vg lvm2 a--  <20.00g  <10.00g

$ sudo vgs
  VG      #PV #LV #SN Attr   VSize  VFree
  data_vg   2   1   0 wz--n- 39.99g <10.00g

$ sudo lvs
  LV   VG      Attr       LSize  Pool Origin Data%  Meta%
  app  data_vg -wi-ao---- 30.00g

The details are shown by pvdisplay, vgdisplay and lvdisplay. The overall picture together with ordinary partitions is given by lsblk: logical volumes appear there with the type lvm.

$ lsblk /dev/sdb /dev/sdc
NAME             MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sdb                8:16   0  20G  0 disk
└─data_vg-app    253:0    0  30G  0 lvm  /srv/app
sdc                8:32   0  20G  0 disk
└─data_vg-app    253:0    0  30G  0 lvm  /srv/app

Here the 30 GB app volume lies on two 20 GB disks at once — this cannot be done with an ordinary partition.

LVM from scratch: from a raw disk to a mounted volume

Suppose an empty disk /dev/sdb has been added to the server, and a 15 GB volume is needed for the application data. Check the disk name with lsblk twice: all the commands below destroy the data on the specified device.

Step 1. Create a physical volume

$ sudo pvcreate /dev/sdb
  Physical volume "/dev/sdb" successfully created.

You can give LVM the whole disk, or first create a partition with fdisk or parted with the type "Linux LVM" and specify it (/dev/sdb1). A partition is clearer for other administrators and protects against accidentally partitioning the disk over LVM; a whole disk is easier to extend in the cloud.

Step 2. Create a volume group

$ sudo vgcreate data_vg /dev/sdb
  Volume group "data_vg" successfully created

Step 3. Carve out a logical volume

$ sudo lvcreate -n app -L 15G data_vg
  Logical volume "app" created.

The -L flag sets an absolute size, -l sets the size in extents or percentages: -l 100%FREE takes all the free space of the group, -l 50%VG takes half of the group. Leaving a spare reserve in the VG is good practice: it can later be added to any volume or used for a snapshot.

Step 4. Filesystem and mounting

$ sudo mkfs.ext4 /dev/data_vg/app
$ sudo mkdir -p /srv/app
$ sudo mount /dev/data_vg/app /srv/app
$ df -h /srv/app
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/data_vg-app   15G   24K   14G   1% /srv/app

To have the volume mounted after a reboot, add a line to /etc/fstab. For logical volumes the /dev/mapper/... path is stable, so you can use it or the UUID from blkid:

/dev/mapper/data_vg-app  /srv/app  ext4  defaults  0 2

Check the entry with sudo mount -a before rebooting: a mistake in fstab can leave the server in emergency mode.

How to extend an LVM volume without stopping the service

This is the main reason to like LVM. The volume grows on a mounted filesystem while the application keeps writing data. The procedure depends on whether the group has free space.

If the VG has free space

$ sudo vgs data_vg
  VG      #PV #LV #SN Attr   VSize   VFree
  data_vg   1   1   0 wz--n- <20.00g <5.00g

$ sudo lvextend -r -L +4G /dev/data_vg/app
  Size of logical volume data_vg/app changed from 15.00 GiB to 19.00 GiB.
  Logical volume data_vg/app successfully resized.
resize2fs 1.47.0
Filesystem at /dev/mapper/data_vg-app is mounted on /srv/app; on-line resizing required

The key flag is -r (--resizefs): right after enlarging the volume it also extends the filesystem. Without it the volume becomes larger, but df -h shows the old size, because the filesystem does not know about the new space. This is the most common mistake: in that case it is enough to run resize2fs for ext4 or xfs_growfs for XFS manually.

$ sudo resize2fs /dev/data_vg/app      # ext4, the device is specified
$ sudo xfs_growfs /srv/app             # XFS, the mount point is specified

Note the sign: -L +4G adds 4 GB, while -L 4G sets the final size to 4 GB. To give the volume all the remaining space, use -l +100%FREE.

If the VG has run out of space: add a disk

Attach the new disk (in the cloud — attach a volume), find it with lsblk and add it to the group:

$ sudo pvcreate /dev/sdc
$ sudo vgextend data_vg /dev/sdc
  Volume group "data_vg" successfully extended
$ sudo lvextend -r -l +100%FREE /dev/data_vg/app

Three commands, zero downtime. The filesystem now lies on two disks, and the application does not notice.

If the disk was enlarged in the cloud

In the cloud it is often easier not to add a disk but to enlarge the existing one. Then the kernel sees the new device size, and the physical volume must be stretched with the pvresize command:

$ sudo pvresize /dev/sdb
  Physical volume "/dev/sdb" changed
$ sudo lvextend -r -l +100%FREE /dev/data_vg/app

If the PV was created on a partition (/dev/sdb1), first grow the partition, for example with the growpart /dev/sdb 1 utility from the cloud-guest-utils package, and only then run pvresize /dev/sdb1.

Can an LVM volume be shrunk

It can, but not for every filesystem and not on the fly. XFS cannot be shrunk at all — it can only be recreated with the data moved. Ext4 can be shrunk, but only when unmounted:

$ sudo umount /srv/app
$ sudo lvreduce -r -L 10G /dev/data_vg/app

With the -r flag LVM checks the filesystem itself (e2fsck) and shrinks it before shrinking the volume. Without -r it is easy to cut the volume smaller than the filesystem and damage the data. Always make a backup before shrinking.

LVM snapshots: a copy of a volume before a risky operation

A snapshot is an instant copy of a logical volume. It is created in a fraction of a second and does not copy the data: LVM works on the copy-on-write principle and saves to the snapshot only those blocks that change on the original volume after it was created. So the snapshot needs space in the VG only for the changes, not for the whole volume.

$ sudo lvcreate -s -n app_before_upgrade -L 2G /dev/data_vg/app
  Logical volume "app_before_upgrade" created.

$ sudo lvs data_vg
  LV                 VG      Attr       LSize  Origin Data%
  app                data_vg owi-aos--- 19.00g
  app_before_upgrade data_vg swi-a-s---  2.00g app    0.01

The Data% column shows how full the change storage is. If it reaches 100%, a classic snapshot becomes invalid, and the only option left is to delete it. Choose the size with a margin for the expected amount of changes, and watch long-lived snapshots through lvs or extend them with lvextend.

How to roll back to a snapshot

If the update went badly, return the volume to its state at the moment of the snapshot:

$ sudo umount /srv/app
$ sudo lvconvert --merge /dev/data_vg/app_before_upgrade
  Merging of volume data_vg/app_before_upgrade started.
$ sudo mount /srv/app

After the merge the snapshot disappears. If the volume cannot be unmounted (for example, it is the system root), the merge is postponed until the next activation of the volume, that is, until the reboot.

If everything went well

The snapshot is simply deleted, so that it does not slow down writes or occupy space:

$ sudo lvremove /dev/data_vg/app_before_upgrade

A snapshot is convenient to mount read-only in order to take a consistent backup of a running system: mount -o ro and copy with rsync or tar. For XFS add the nouuid option, otherwise the mount fails because the UUID matches the original.

LVM and RAID: do not confuse the tasks

LVM alone does not protect against a disk failure. If a volume is stretched over two disks and one of them dies, the whole volume is lost, not half of it. For fault tolerance, RAID (mdadm) is placed under LVM, or the mirror mode built into LVM is used (lvcreate --type raid1 -m 1).

And neither RAID nor snapshots replace a backup. A snapshot lives on the same disks as the original, and RAID faithfully mirrors even an accidental rm -rf. You need a separate copy on another medium.

LVM command cheat sheet

Common mistakes

• The volume was extended, but df shows the old size. The -r flag was forgotten. Run resize2fs or xfs_growfs.
• Insufficient free space. The group has no free extents: check vgs and add a disk with vgextend or stretch the PV.
• Device /dev/sdc excluded by a filter. The disk still has an old partition table or filesystem signature. If the data on it is definitely not needed, clear it with wipefs -a /dev/sdc.
• The snapshot became Invalid. The change storage filled up to 100%. It cannot be recovered — it can only be deleted, and next time more space must be allocated.

Summary

LVM in Linux has three layers: physical volumes (PV) are combined into a group (VG), from which logical volumes (LV) are carved. This gives what ordinary partitions lack: growing a volume on the fly with lvextend -r, adding disks without downtime, and snapshots before risky changes. Remember that LVM replaces neither RAID nor backups. Disk partitioning, LVM, RAID and quotas are covered with practice in the Linux course lecture.