LVM: flexible storage

Volumes, resizing, and snapshots.

Advanced14 min · lesson 8 of 17

Raw disk partitions are rigid — a partition is a fixed slice of one disk, and growing it or spanning disks is painful. LVM (Logical Volume Manager) adds a flexible layer in between so storage stops being tied to physical boundaries. It has three levels: physical volumes (PVs) are the raw disks or partitions you hand to LVM; a volume group (VG) is a pool combining one or more PVs; and logical volumes (LVs) are the flexible "partitions" you carve out of the pool and put filesystems on. Because LVs draw from the pool, you can resize them, grow across disks, and snapshot them.

The LVM stack
1physical volumes
raw disks/partitions (PV)
2volume group
one pool of space (VG)
3logical volumes
flexible "partitions" (LV)
4filesystem
ext4/xfs on each LV
Space flows disks → pool → volumes. Add a disk to the pool, and any volume can grow into it — no repartitioning.

Creating and growing

The everyday power of LVM is online growth. When a volume fills up, you extend it from the pool’s free space and grow the filesystem on top — often without unmounting, with no downtime. Add a new disk to the volume group first if the pool itself is out of space. This is why servers that matter use LVM: "the disk is full" becomes "extend the volume," a two-command fix instead of a repartition-and-restore.

terminal
$ sudo pvcreate /dev/sdb # make a disk into a physical volume
$ sudo vgextend data-vg /dev/sdb # add it to the pool
$ sudo lvextend -L +50G /dev/data-vg/app # grow the logical volume by 50G
$ sudo resize2fs /dev/data-vg/app # grow the ext4 filesystem to match (xfs: xfs_growfs)
# often all doable while mounted — no downtime

Snapshots

An LVM snapshot captures a volume’s state at a moment in time, cheaply, by recording only subsequent changes (copy-on-write). The classic use is a consistent backup: snapshot the volume, back up the frozen snapshot at leisure while the live volume keeps changing, then delete the snapshot. Snapshots are also a safety net before a risky change — snapshot first, and if it goes wrong, roll back. They are not a substitute for real backups (they live on the same disks), but they are invaluable for consistency and quick rollback.

terminal
$ sudo lvcreate -s -n app-snap -L 5G /dev/data-vg/app # snapshot (5G for changes)
$ sudo mount -o ro /dev/data-vg/app-snap /mnt/snap # back up the frozen point-in-time
$ sudo lvremove /dev/data-vg/app-snap # remove when done
$ sudo lvs # list logical volumes + snapshot usage
A snapshot that fills up is invalidated
An LVM snapshot only reserves space for the changes since it was taken — if the live volume changes more than the snapshot’s allocated size, the snapshot fills and becomes invalid (unreadable), silently breaking your backup. Size snapshots for the expected write volume during their lifetime, monitor lvs for a snapshot approaching 100%, and delete them promptly after use — a lingering snapshot also imposes a copy-on-write performance cost on every write to the origin. Snapshots are cheap and powerful but not free or permanent.