LVM: Resizing and Snapshots

LVM Basics built a PV → VG → LV structure. LVM's main practical benefit shows up here: an LV's size can be changed while it's in use, with no need to repartition the disk at all, and it can be snapshotted in an instant.

What You Will Learn

By the end of this article you will be able to:

• extend an LV with lvextend and resize its filesystem to match;
• explain why shrinking an LV is risky and how to do it more safely;
• create a snapshot with lvcreate -s and explain how it works;
• use a snapshot to roll back changes, or to preserve data;
• explain why a snapshot running out of space is dangerous.

Extending an LV

If the VG has free space, an LV can be extended while it's in use. This is a two-step process: first at the LVM level, then at the filesystem level.

1. Check free space in the VG

sudo vgs vg_data

The VFree column shows how much free space is available. If there's none, a new PV needs to be added to the VG first:

sudo pvcreate /dev/sdd
sudo vgextend vg_data /dev/sdd

2. Extend the LV

sudo lvextend -L +10G /dev/vg_data/lv_app

+10G is the amount added to the current size (not the absolute new size). To give it all the free space:

sudo lvextend -l +100%FREE /dev/vg_data/lv_app

3. Resize the filesystem to match the new size

lvextend only changes the block device's size — the filesystem doesn't automatically know about it. An extra command is needed, depending on the filesystem type.

For ext4:

sudo resize2fs /dev/vg_data/lv_app

For xfs (can only be extended while mounted):

sudo xfs_growfs /mnt/app

Instead of running both commands separately, ext4 can be done in one action:

sudo lvextend -r -L +10G /dev/vg_data/lv_app

The -r flag automatically calls the matching resize command after lvextend.

Checking:

df -hT /mnt/app
lvs vg_data/lv_app

Shrinking an LV — Why Caution Is Needed

Extending is safe and almost always done online. Shrinking works differently: the filesystem must first be shrunk itself, and only then can the LV be resized to that new, smaller size — the reverse order from extending.

The correct order for ext4 (unmounting the filesystem first is recommended):

sudo umount /mnt/app
sudo e2fsck -f /dev/vg_data/lv_app
sudo resize2fs /dev/vg_data/lv_app 15G
sudo lvreduce -L 15G /dev/vg_data/lv_app
sudo mount /dev/vg_data/lv_app /mnt/app

Since shrinking isn't supported on xfs, the usual approach when needed is: create a new, smaller LV, copy the data over with rsync, then delete the old LV.

Shrinking in production should never be done without a verified backup and a maintenance window.

Snapshots: What They Are and How They Work

A snapshot "freezes" an LV's state at a particular moment, presenting it as a separate LV. Creating a snapshot doesn't copy the full set of files at that instant — LVM only tracks blocks that later change on the original LV (copy-on-write).

lv_app (original)  ──snapshot──>  lv_app_snap (state at that moment)
     │
     └─ subsequent writes only affect lv_app,
        lv_app_snap keeps showing the unchanged state

Creating a Snapshot

sudo lvcreate -s -n lv_app_snap -L 2G /dev/vg_data/lv_app

• -s — snapshot creation mode;
• -n lv_app_snap — the snapshot's name;
• -L 2G — space reserved for the snapshot. This is not the original LV's size — only a reserve for tracking changed blocks.

Checking:

sudo lvs -o+lv_size,origin,data_percent

The Origin column shows which LV the snapshot was taken from, and Data% shows how full the snapshot's reserve currently is.

Mounting a Snapshot to Inspect It

sudo mkdir -p /mnt/app_snap
sudo mount -o ro /dev/vg_data/lv_app_snap /mnt/app_snap

Mounting a snapshot read-only is recommended — that's the whole point of a snapshot: inspecting the state at that moment, or backing it up.

Rolling Back from a Snapshot (Restoring the Original LV to a Previous State)

sudo umount /mnt/app
sudo lvconvert --merge /dev/vg_data/lv_app_snap

lvconvert --merge restores the snapshot's state back into the original LV, destroying the snapshot in the process. If the LV is actively in use, completing the merge often requires a reboot or reactivating the VG — read the command's output warning carefully.

Removing a Snapshot (Without Rolling Back)

If a snapshot was only used for temporary inspection or backup, and changes to the original LV need to be kept:

sudo umount /mnt/app_snap
sudo lvremove /dev/vg_data/lv_app_snap

This deletes the snapshot entirely and has no effect on the original LV.

Classic (Thick) vs. Thin Snapshots

The snapshot created above with lvcreate -s -L 2G is a classic (thick) snapshot: a fixed chunk of the VG is reserved up front, and if writes to the origin exceed that reserve, the snapshot goes invalid (unusable). Modern LVM offers an alternative — thin snapshots — carved from a thin pool instead:

sudo lvcreate -L 50G -T vg_data/thinpool          # create a thin pool
sudo lvcreate -V 20G -T vg_data/thinpool -n lv_app  # a thin LV inside it
sudo lvcreate -s -n lv_app_snap vg_data/lv_app    # snapshot: no -L needed

The performance note still applies to both: while a classic snapshot exists, every write to the origin triggers a copy-on-write of the old block into the snapshot, so heavy write workloads run slower until the snapshot is removed. The danger simply moves from "the snapshot fills" (classic) to "the pool fills" (thin) — with thin pools, monitor the pool's Data%, and configure thin_pool_autoextend_threshold so it grows before it's exhausted.

When to Use a Snapshot

Common Mistakes

Sizing a Snapshot Too Small

A snapshot's -L size should be chosen based on how much the original LV is expected to change, not the original LV's size. A small snapshot on a heavily written LV fills up quickly and goes invalid.

Forgetting resize2fs/xfs_growfs

lvextend only changes the block device's size. Until the matching filesystem-level command runs, df keeps showing the old size.

Trying to Shrink xfs

xfs_growfs only grows. If shrinking is needed, the fix is replacing the LV (new LV + data migration), not the filesystem.

Exercises

1. In a disposable VM, extend the lv_app LV left over from the previous article by 5 GiB and confirm the result with df -hT.
2. Take a 1 GiB snapshot of lv_app, write a file to it (to the original LV, not the snapshot), then mount the snapshot and watch the Data% value.
3. Roll back from the snapshot with --merge and confirm the file is gone from the original LV.
4. Shrink an ext4 LV in the correct order (unmount → fsck → resize2fs → lvreduce) and verify the result at each step.

Verification criterion: given a filesystem type (ext4 or xfs) and a target action (extend or shrink), you should be able to state whether it's supported online, offline, or not at all.

Summary

lvextend (with -r if needed) extends an LV and its filesystem together, usually online; lvreduce requires the reverse order — filesystem first, then LV — and isn't supported at all on xfs. A snapshot preserves an LV's state at a point in time through copy-on-write, and can be restored with lvconvert --merge or discarded with lvremove. Both depend on free space in the VG — which is why the monitoring covered in Disk Usage and Disk-Full Troubleshooting stays just as relevant in an LVM environment.

References

• man7.org: lvextend(8)
• man7.org: lvreduce(8)
• man7.org: lvcreate(8)
• man7.org: lvconvert(8)
• Red Hat: Snapshot volumes