Logical Volume Management (LVM)

Everything in this section so far has assumed a fixed relationship: one partition, one filesystem, one mount point, sized once at creation and difficult to change afterward. That rigidity is a real, practical problem — and LVM (Logical Volume Management) exists specifically to solve it, by inserting a flexible layer between raw disks and the filesystems that sit on top of them.

The Problem With Plain Partitions

Picture a straightforward scenario: a partition holding a database’s data grows over months, and eventually runs low on space. With the plain partitioning approach from earlier in this section, your options are all genuinely painful — back up the data, delete the partition, recreate it larger (assuming there’s even contiguous free space next to it, which there often isn’t), reformat, and restore. That’s real downtime and real risk, for a problem that’s going to recur the next time the volume fills up again.

There’s a second problem, too: a plain partition is permanently tied to one physical disk. If that disk runs out of room entirely, a plain partition has no way to simply span onto a second disk — you’d need an entirely different mechanism to combine storage across multiple physical devices.

LVM solves both problems at once, by making “how big is this storage” and “which physical disk is it actually on” into questions you can answer flexibly, after the fact, instead of committing to them permanently at creation time.

Three Layers: PV, VG, LV

LVM introduces three concepts, each building on the one before it.

Physical Volume (PV) — a disk or partition that’s been initialized for LVM use. This is the raw physical storage LVM is allowed to manage — conceptually similar to a plain partition from earlier in this section, except instead of formatting it directly with a filesystem, you hand it to LVM instead.

Volume Group (VG) — a pool of storage created by combining one or more physical volumes together. This is the layer where LVM’s real flexibility comes from: a single volume group can span multiple physical disks, and its total available space is simply the sum of every PV assigned to it. Adding more storage to a system, from LVM’s perspective, is often as simple as adding a new disk as another PV and folding it into an existing VG.

Logical Volume (LV) — a “virtual partition” carved out of a volume group’s available space. This is what you actually format with a filesystem (ext4, xfs, whichever fits) and mount, exactly like a plain partition would be — except its size isn’t tied to any single physical disk’s boundaries, and it can be resized later far more easily than a plain partition ever could be.

    flowchart LR
    A["Physical Disk 1<br/>(PV)"] --> C["Volume Group"]
    B["Physical Disk 2<br/>(PV)"] --> C
    C --> D["Logical Volume 1"]
    C --> E["Logical Volume 2"]
    D --> F["Filesystem (ext4/xfs)"]
    E --> G["Filesystem (ext4/xfs)"]
    F --> H["Mounted at /data"]
    G --> I["Mounted at /backups"]
  

Notice that a single volume group can be carved into multiple logical volumes, each independently sized, formatted, and mounted wherever needed — while still drawing from the same underlying pool of physical storage, potentially spread across several disks.

Revisiting The Database Scenario, With LVM

The same running-low-on-space situation from earlier looks very different under LVM: add a new disk, initialize it as a PV, extend the existing volume group to include it, then extend the logical volume (and, separately, the filesystem sitting on it) to use the newly available space — all without needing to touch the data already on the volume, and typically without significant downtime. This is exactly the hands-on sequence the next chapter walks through directly.

Why This Isn’t The Default Everywhere

Given how much more flexible this sounds, it’s worth asking why plain partitions still exist and remain common at all. The honest answer is that LVM is a genuinely added layer of complexity — another set of concepts and commands to understand, another place things can go wrong, and another layer to keep in mind while debugging a storage issue, on top of everything already covered in this section.

There’s also the boot partition consideration from earlier in this section: bootloaders historically have had trouble reading directly from inside an LVM logical volume, which is exactly why /boot is commonly kept as its own plain, non-LVM partition even on systems where the rest of the storage uses LVM extensively — a detail that will make direct, practical sense once you see it addressed in a real setup in the next chapter.

Snapshots: A Preview

One capability worth knowing exists, even though the hands-on details are outside this fundamentals course’s scope: LVM can create snapshots — a point-in-time copy of a logical volume’s state, useful for things like taking a safe backup of a live system without stopping it, or having a fast rollback point before a risky change. This is conceptually similar to what btrfs offers natively, from the Filesystems chapter — LVM brings that same snapshot capability to ext4 and xfs, which don’t have it built in on their own.

What’s Next

With the concepts in place — why LVM exists, and what PVs, VGs, and LVs each actually are — the next chapter makes all of this concrete: creating a volume group from real disks, carving out a logical volume, and extending it, using the exact commands that turn this three-layer model into something you can actually operatechapter