Once a traditional partition is fixed in place, resizing means touching the partition table — high risk, and often requiring downtime. LVM (Logical Volume Manager) adds a layer of abstraction between physical disks and filesystems, letting storage space be allocated on demand and resized online like memory. This article explains LVM’s core concepts, applicable scenarios, and the complete flow of building a volume from scratch in one pass. Volume creation, expansion, and shrink safeguards were all tested on a Rocky Linux 9.3 container (lvm2 2.03.33) with two loop disks.

Three Core Concepts

LVM’s storage virtualization rests on a three-layer structure:

  • Physical Volume (PV): the basic unit at the bottom — a whole disk or a partition, handed to LVM after initialization.
  • Volume Group (VG): pools multiple physical volumes into one storage pool, with capacity scheduled uniformly within it.
  • Logical Volume (LV): usable space carved out of the volume group — an enhanced partition, in effect, one that can be resized dynamically without affecting existing data.

One sentence to tie it together: disks are initialized into PVs, PVs are pooled into a VG, and an LV is the “partition” cut from the pool that gets formatted and mounted directly. The pool is not infinitely divisible: space is sliced into PEs (Physical Extents, 4MB by default), so an LV’s capacity can only be an integer multiple of the PE — which explains the later phenomenon of “asking for 30M and getting 32M”.

When LVM Fits

  1. Dynamic storage adjustment: the business grows and needs more space — add capacity to a logical volume online without interrupting service.
  2. Snapshots: snapshot a logical volume for backup and recovery — an insurance policy before upgrades.
  3. Disk mirroring and striping: improve data reliability or read/write speed.

The counterexample is equally clear: single machines with small disks and a capacity structure you can see the end of from a mile away are simpler with plain partitions — no need to pay a learning cost for an extra layer of abstraction.

Installation is one command: Rocky 9/CentOS uses dnf install lvm2, Debian/Ubuntu uses apt install lvm2 — mainstream distributions usually include it by default at install time.

Hands-On: From Two Disks to One Usable Logical Volume

Suppose we have two disks, /dev/sdb and /dev/sdc, and the goal is to build a 30G logical volume and mount it (the real test substituted 60M loop disks, scaled down proportionally).

Step 1: Create physical volumes

1
sudo pvcreate /dev/sdb /dev/sdc

Step 2: Create a volume group

The two disks form a storage pool named my_volume_group:

1
sudo vgcreate my_volume_group /dev/sdb /dev/sdc

Step 3: Create a logical volume

Allocate 30G from the volume group:

1
sudo lvcreate -L 30G -n my_logical_volume my_volume_group

The full three-step chain as tested (loop disk paths in place of sdb/sdc; the container kernel could not zero the newly created LV, so lvcreate carried -Z n -W n to skip zeroing — real machines don’t need these two flags):

Figure 1

A detail in the tested output: we asked for 30M, and lvs shows 32.00m — LV capacity rounds up to the PE boundary. So “asked for 30G, got 30.0G” is not necessarily exact; keep it in mind when planning capacity.

Step 4: Format

1
sudo mkfs.ext4 /dev/my_volume_group/my_logical_volume

Step 5: Mount

1
2
sudo mkdir /mnt/my_storage
sudo mount /dev/my_volume_group/my_logical_volume /mnt/my_storage

Verification points: df -h /mnt/my_storage shows the new filesystem, and the LV appears under the volume group tree in lsblk.

When writing /etc/fstab for mounting at boot, prefer the device name /dev/mapper/my_volume_group-my_logical_volume or the UUID (check with blkid), never bare disk names like /dev/sdb — disk ordering can drift after a reboot, and getting it wrong hangs the boot.

Example: Online Expansion (LVM’s Signature Move)

After writing 10M of data, expand the LV from 30M to 50M, without unmounting at any point:

1
2
3
# Expand the logical volume first, then the filesystem — both steps required
sudo lvextend -L 50G /dev/my_volume_group/my_logical_volume
sudo resize2fs /dev/my_volume_group/my_logical_volume   # ext4 supports online expansion

As tested (the 50M target actually landed on the 52M PE boundary):

Figure 2

Result: capacity 26M→44M, mount never dropped, and the md5 of the data.bin written beforehand matched before and after. Note that lvextend only grows the “container” — the filesystem must follow with resize2fs. If you run only lvextend, df doesn’t change — the classic beginner’s “expanded into nothing”. The XFS equivalent is xfs_growfs <mountpoint>, and XFS can only grow, never shrink.

The VG pool itself can grow too: when lvextend reports Insufficient free space, it’s time to restock the pool — add a new disk, initialize it as a PV, and fold it into the VG, two steps:

1
2
sudo pvcreate /dev/sdd
sudo vgextend my_volume_group /dev/sdd

With the VG enlarged, lvextend has material to carve. The whole expansion chain is fully online — that is exactly the value of the “pool” structure: disk, pool, and volume each scale independently, with no downtime for any of them.

Comparison Traditional partitions LVM
Expansion Touch the partition table, often needs downtime Online lvextend + resize2fs
Cross-disk aggregation Not supported VG aggregates multiple disks natively
Snapshots Requires filesystem-level support Native LV-level snapshots
Shrinking Equally dangerous Equally dangerous (shrink fs first, then LV)

Example: Snapshots

An insurance policy before upgrading or changing configuration:

1
sudo lvcreate -s -L 5G -n my_snap /dev/my_volume_group/my_logical_volume

A snapshot is a read-only copy of one instant in time (COW mechanism: changes go to the original volume, and old data is frozen into the snapshot volume); mount it and copy the data straight out. Recovery goes the other way with dd or restore tools. Don’t make the snapshot volume too small — the more the original volume changes, the more space the snapshot consumes, and once it fills, the snapshot becomes invalid.

Note: this command was not actually run — the experiment container’s kernel lacks the dm-snapshot target (it reported “Required device-mapper target(s) not detected in your kernel”); real server kernels ship the module.

Wrong-Operation Comparison: Shrinking Directly with lvreduce

Expansion is safe; shrinking is dangerous. Running lvreduce -L 10M directly on a formatted LV in the real test popped the tool’s safeguard gate:

Figure 3

It detected ext4 inside, refused to shrink, and demanded that the filesystem be shrunk first with resize2fs (or --resizefs passed explicitly). The ways around this gate — switching device names, adding force flags — are where data loss begins: if the part cut off the LV still holds filesystem data, it is corrupted outright. The iron rule of shrinking: shrink the filesystem first, then the logical volume — the order must never be reversed.

Command Quick Reference

Command Purpose
pvs / vgs / lvs One-line summaries of PV/VG/LV
pvdisplay / vgdisplay / lvdisplay Object details
lvextend -L +10G Add 10G to an LV (pair with resize2fs)
lvextend -l +100%FREE Give all remaining VG space to an LV
lvcreate -s Create a snapshot volume
lvremove / vgremove / pvremove Tear down layer by layer (unmount first; LV→VG→PV order)

Notes

  • Back up important data before any LVM operation; expansion is safe and shrinking is dangerous, and wrong lvreduce parameters destroy data outright.
  • Flexibility doesn’t eliminate planning — VG capacity still needs to be estimated against the business.
  • Snapshots and mirrors carry extra performance overhead; evaluate the impact before enabling them in production.
  • LV capacity rounds to the PE boundary (30M landed on 32M in testing); precise capacity planning must account for PE granularity.
  • Never scramble the teardown order: umount first, then lvremove, vgremove, pvremove — skipping layers gets rejected or leaves residue.
  • On “Device /dev/sdb not found”, first verify the disk name and multipath aliases; on “No free physical extents”, the disk is most likely already claimed by another VG.

Pros and Cons Summary

Pros: resizing logical volumes and volume groups is easy (tested: expansion fully online, shrink safeguard gate reliable); snapshot support for backup and recovery; managing storage devices is more efficient than raw partitions.

Cons: a learning curve for newcomers; extra metadata and processing overhead that can affect performance in extreme scenarios; managing VGs/LVs takes some configuration experience.

On balance: systems that need dynamic expansion or high-availability storage should default to LVM; single machines with small disks and a fixed structure are simpler with plain partitions. Back to the opening’s “partition fixed in place”: LVM’s answer is to turn the “partition” into a ladle of water in a pool — lvextend + resize2fs, two steps, no service interruption. That is what the extra layer of abstraction buys.

This article was restructured from the author’s 2020-2024 CSDN blog posts, originally published on CSDN.