LVM — Logical Volume Manager

Btrfs and ZFS (fs1-3, fs1-4) manage volumes themselves, internally. This chapter is about the traditional alternative for filesystems that don't — ext4 and XFS most commonly — a separate layer purpose-built to sit between raw storage and the filesystem: LVM, the Logical Volume Manager. It's also the chapter that finally delivers on a promise grub1-8 deliberately left open.

The PV/VG/LV Model

• Physical Volume (PV) — a raw disk or partition initialized for LVM's use.
• Volume Group (VG) — a pool combining one or more PVs into a single pool of storage, potentially spanning multiple physical disks.
• Logical Volume (LV) — a "virtual partition" carved out of a VG — this is what actually gets formatted with a filesystem and mounted.

Why This Extra Layer Exists — Flexibility

The value LVM adds beyond a plain partition: a logical volume isn't tied to the physical geometry of a single disk. A volume group can span multiple physical disks, so a logical volume can be larger than any single disk in the machine. And, most importantly, logical volumes can be resized live — without unmounting, without downtime, and without the rigid fixed-size commitment a plain partition forces at creation time.

Live Resizing — LVM's Real Payoff

Growing a logical volume can be done while it's mounted and actively in use:

Shrinking is genuinely riskier, and the order matters: the filesystem must be shrunk first (resize2fs to the smaller target size), and only then can the logical volume itself be reduced (lvreduce). Doing it in the wrong order truncates the logical volume out from under data the filesystem still thinks it owns — see the warn-box below.

Delivering on grub1-8's Deferred Promise

grub1-8 deliberately deferred LVM considerations in the context of multi-boot partitioning. Here's the real answer: GRUB can boot a root filesystem that lives on an LVM logical volume — grub-mkconfig detects LVM automatically and writes the correct boot parameters. But /boot itself is commonly kept outside LVM, as its own small, plain partition, because GRUB's ability to parse LVM metadata directly to locate a kernel and initrd is more limited and more fragile than reading a plain partition — especially once LVM is layered on RAID, or the volume is encrypted. This is exactly why Debian's own default installer layout (seen back in linux1) carves out a small separate /boot partition even when the rest of the disk uses LVM.

In a real multi-boot setup, this makes LVM genuinely useful: each Linux distribution's own root filesystem can live in its own logical volume within a shared volume group, letting disk space be divided among multiple distros flexibly rather than requiring fixed-size partitions decided up front — while GRUB itself, and ideally /boot, stays on plain partitions for maximum compatibility across every OS involved.

A Worked Example — Growing a Live Filesystem

Hands-On Exercises