LFCS 87 🐧 LVM — Reducing Volumes - KandZ

⏱️ Estimated read: 11 min | |

Reducing a Logical Volume is the operation that LVM permits and the filesystem may forbid. The LV can always be shrunk; the filesystem on it cannot. ext4 supports shrinking, but only offline. XFS does not support shrinking at all. The workflow therefore begins with the filesystem type, not with lvreduce, and the order of operations is the inverse of extension: shrink the filesystem first, then reduce the LV. Reversing the order destroys the data in the extents being removed.

This chapter covers the reduction workflow for ext4 and the reasons XFS is excluded. It assumes the LV creation and extension from the previous chapters. The focus is on the safe sequence—unmount, check, resize filesystem, reduce LV—and the failure modes that make this the most dangerous LVM operation.

Key point: lvreduce does not know what the filesystem is using. It removes extents from the end of the LV regardless of whether the filesystem has data there. The filesystem must be shrunk first, so that the extents being removed are already free.

Why reduction is different from extension

The filesystem constraint. Extension works because the filesystem can be told to use more space. Reduction requires the filesystem to give space back, and not every filesystem can. ext4 can shrink with resize2fs, but only while unmounted . XFS cannot shrink at all; the XFS documentation and the LFCS exam traps both state that XFS is grow-only . The LV reduction workflow is therefore only applicable to ext4 (and Btrfs, which is outside this LVM chapter’s scope).

The data loss hazard. lvreduce removes Logical Extents from the LV’s mapping. The data in those extents is discarded. If the filesystem still believes it owns those extents, the filesystem’s metadata points to blocks that no longer exist, and the filesystem is corrupted . The warning in the lvreduce man page is explicit: “data in the reduced part is lost” . The only protection is shrinking the filesystem first, so that the extents at the end of the LV are already marked free.

The snapshot constraint. A Logical Volume cannot be reduced while it has snapshots. The Gentoo wiki states that as long as snapshot logical volumes exist, the original LV cannot be reduced or removed . The snapshot must be removed first.

a. The safe reduction sequence for ext4

The sequence has five steps, and the order is mandatory. The Red Hat documentation for RHEL 10 lists them explicitly: list the LV, find the mount point, unmount, check the filesystem, resize the LV and filesystem, then remount and verify .

# 1. Confirm the LV and its current size.
sudo lvs -o lv_name,vg_name,lv_size
# Example output: lv_app vg_data 6.49g

# 2. Confirm the mount point.
findmnt -o SOURCE,TARGET /dev/vg_data/lv_app

# 3. Unmount the filesystem. This is required for ext4 shrink.
sudo umount /mnt/app

# 4. Check the filesystem for errors before shrinking.
# -f forces the check even if the filesystem appears clean.
sudo e2fsck -f /dev/vg_data/lv_app

# 5. Shrink the filesystem to the target size.
# The target must be smaller than the current filesystem size.
sudo resize2fs /dev/vg_data/lv_app 4G

# 6. Reduce the LV to the same target size.
# The LV must not be smaller than the filesystem.
sudo lvreduce -L 4G /dev/vg_data/lv_app

# 7. Remount and verify.
sudo mount /dev/vg_data/lv_app /mnt/app
df -hT /mnt/app
sudo lvs /dev/vg_data/lv_app

The lvreduce command accepts -L for absolute size and -l for extents. The -r flag, which works for extension, also works for reduction: it calls the filesystem resize tool as part of the operation . For ext4, lvreduce -r -L 4G /dev/vg_data/lv_app performs both steps. However, the -r flag is less reliable for XFS and is not a substitute for the filesystem-first discipline when shrinking.

The target size in resize2fs and lvreduce must match. If resize2fs shrinks to 4G and lvreduce reduces to 3G, the LV is smaller than the filesystem, and the filesystem is corrupted. If lvreduce reduces to 4G and resize2fs shrinks to 3G, the LV is larger than necessary but the data is safe.

b. The XFS exclusion and the swap case

XFS cannot be shrunk. The LFCS exam trap list states this as the first storage trap: “XFS cannot shrink; only ext4 (offline) supports shrinking” . An XFS LV is grow-only. The only way to reduce it is to back up the data, remove the LV, create a smaller one, and restore. The lvreduce command will succeed if run on an XFS LV, but the filesystem will be corrupted because it has no way to release the extents that the LV removed.

Swap on LVM is a separate case. Swap is not a filesystem; it is a raw block device formatted with mkswap. To reduce a swap LV, the sequence is: swapoff, lvreduce, mkswap, swapon. The Red Hat documentation for reducing swap on an LVM2 LV lists exactly this sequence . There is no filesystem to shrink first, but the swap must be disabled before the LV is reduced.

# Reduce a swap LV from its current size by 512M.
sudo swapoff -v /dev/vg_data/lv_swap
sudo lvreduce -L -512M /dev/vg_data/lv_swap
sudo mkswap /dev/vg_data/lv_swap
sudo swapon -v /dev/vg_data/lv_swap

c. Verification and the common failure

After the reduction, both layers must be verified. lvs shows the LV size, and df -hT shows the filesystem size. The filesystem size must be less than or equal to the LV size. If the filesystem is larger than the LV, the reduction was performed in the wrong order, and the filesystem is corrupted.

The common failure is running lvreduce before resize2fs. The command succeeds, the LV shrinks, and the filesystem is immediately broken. The symptom is a filesystem that mounts but reports errors, or a fsck that finds inconsistencies. The fix is to restore from backup; there is no safe way to recover the data that was in the removed extents.

A second failure is attempting to shrink a mounted ext4 filesystem. resize2fs requires the filesystem to be unmounted for shrinking. The command will fail with an error if the filesystem is mounted, which is the safe behavior: it prevents the shrink from running while the filesystem is in use.

Complete Example Session

# ============================================
# PART 1: CHECK THE CURRENT STATE
# ============================================
# Confirm the LV and filesystem sizes.

sudo lvs /dev/vg_data/lv_app
df -hT /mnt/app

# ============================================
# PART 2: CHECK FOR SNAPSHOTS
# ============================================
# Snapshots prevent reduction.

sudo lvs -o lv_name,lv_size,pool_lv,origin vg_data

# ============================================
# PART 3: UNMOUNT
# ============================================
# ext4 must be unmounted for shrinking.

sudo umount /mnt/app

# ============================================
# PART 4: CHECK THE FILESYSTEM
# ============================================
# Force a check before shrinking.

sudo e2fsck -f /dev/vg_data/lv_app

# ============================================
# PART 5: SHRINK THE FILESYSTEM
# ============================================
# The filesystem shrinks first.

sudo resize2fs /dev/vg_data/lv_app 4G

# ============================================
# PART 6: REDUCE THE LV
# ============================================
# The LV shrinks to match the filesystem.

sudo lvreduce -L 4G /dev/vg_data/lv_app

# ============================================
# PART 7: REMOUNT AND VERIFY
# ============================================
# Both layers must show the new size.

sudo mount /dev/vg_data/lv_app /mnt/app
df -hT /mnt/app
sudo lvs /dev/vg_data/lv_app

# ============================================
# PART 8: THE XFS CASE
# ============================================
# XFS cannot shrink. The only option is
# backup, recreate, restore.

# sudo lvreduce ...  # would corrupt the XFS filesystem

# ============================================
# PART 9: THE SWAP CASE
# ============================================
# Swap has no filesystem. Disable, reduce, mkswap.

sudo swapoff -v /dev/vg_data/lv_swap
sudo lvreduce -L -512M /dev/vg_data/lv_swap
sudo mkswap /dev/vg_data/lv_swap
sudo swapon -v /dev/vg_data/lv_swap

# ============================================
# PART 10: THE FULL PICTURE
# ============================================
# resize2fs first, lvreduce second.
# XFS cannot shrink.
# Swap is disabled before reduction.

echo "Reduction workflow complete."

The ten parts walk through the ext4 reduction, the snapshot check, the XFS exclusion, and the swap case. The sequence is the same for any ext4 LV; the only variation is the swap path, which has no filesystem to shrink.

Quick Reference

Reduction Sequence (ext4)

Step	Command	Effect
1	`lvs`	Confirm LV size
2	`umount /mount`	Unmount the filesystem
3	`e2fsck -f /dev/vg/lv`	Check for errors
4	`resize2fs /dev/vg/lv SIZE`	Shrink the filesystem
5	`lvreduce -L SIZE /dev/vg/lv`	Reduce the LV
6	`mount` + `df -h`	Verify

Filesystem Support

Filesystem	Shrink	Command
ext4	Yes, offline	`resize2fs`
XFS	No	None
Btrfs	Yes, online	`btrfs filesystem resize`

lvreduce Options

Option	Effect
`-L SIZE`	Absolute size
`-L -SIZE`	Reduce by SIZE
`-l EXTENTS`	Size in extents
`-r`	Resize filesystem too
`-f`	Force without prompt

Constraints

Constraint	Consequence
Snapshot exists	Cannot reduce
XFS filesystem	Cannot shrink
Mounted ext4	Cannot shrink
LV smaller than filesystem	Corruption

Best Practices

✅ Do This:

# Shrink the filesystem first.
sudo resize2fs /dev/vg_data/lv_app 4G                                 // ✅
sudo lvreduce -L 4G /dev/vg_data/lv_app                               // ✅

# Check for snapshots before reducing.
sudo lvs -o lv_name,pool_lv,origin vg_data                            // ✅

# Force a filesystem check before shrinking.
sudo e2fsck -f /dev/vg_data/lv_app                                    // ✅

# Verify both layers after reduction.
df -hT /mnt/app && sudo lvs /dev/vg_data/lv_app                       // ✅

❌ Don’t Do This:

# Don't reduce the LV before the filesystem.
sudo lvreduce -L 4G /dev/vg_data/lv_app  # data loss                  // ❌

# Don't try to shrink XFS.
# XFS is grow-only.                                                   // ❌

# Don't shrink a mounted ext4 filesystem.
sudo resize2fs /dev/vg_data/lv_app 4G  # while mounted: fails         // ❌

# Don't reduce an LV with snapshots.
sudo lvreduce ...  # fails: snapshot exists                           // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Filesystem corrupted	`lvreduce` run before `resize2fs`	Restore from backup
`resize2fs` fails	Filesystem mounted	Unmount first
`lvreduce` fails	Snapshot exists	Remove the snapshot
XFS cannot shrink	XFS does not support shrinking	Backup, recreate, restore
Swap reduction fails	Swap still active	`swapoff` first
Target size mismatch	`resize2fs` and `lvreduce` different sizes	Use the same value

Real-World Examples

1. Check LV Size

sudo lvs -o lv_name,lv_size

2. Unmount

sudo umount /mnt/app

3. Check Filesystem

sudo e2fsck -f /dev/vg_data/lv_app

4. Shrink ext4

sudo resize2fs /dev/vg_data/lv_app 4G

5. Reduce LV

sudo lvreduce -L 4G /dev/vg_data/lv_app

6. Verify

df -hT /mnt/app && sudo lvs /dev/vg_data/lv_app

7. Reduce Swap

sudo swapoff -v /dev/vg_data/lv_swap && sudo lvreduce -L -512M /dev/vg_data/lv_swap

8. Recreate Swap

sudo mkswap /dev/vg_data/lv_swap && sudo swapon -v /dev/vg_data/lv_swap

9. Check Snapshots

sudo lvs -o lv_name,origin

10. XFS Alternative

# Backup, remove, recreate, restore.

Visual

The Reduction Sequence

┌─────────────────────────────────────────────────────────┐
│  1. umount /mnt/app                                     │
│         │                                               │
│         ▼                                               │
│  2. e2fsck -f /dev/vg/lv                                │
│         │                                               │
│         ▼                                               │
│  3. resize2fs /dev/vg/lv 4G   ← filesystem shrinks      │
│         │                                               │
│         ▼                                               │
│  4. lvreduce -L 4G /dev/vg/lv  ← LV shrinks            │
│         │                                               │
│         ▼                                               │
│  5. mount + df -h            ← verify                   │
└─────────────────────────────────────────────────────────┘

The Wrong Order

┌─────────────────────────────────────────────────────────┐
│  lvreduce -L 4G /dev/vg/lv                              │
│         │                                               │
│         ▼  LV shrinks to 4G                             │
│  filesystem still 6G                                    │
│         │                                               │
│         ▼  filesystem metadata points to extents        │
│            that no longer exist                         │
│  CORRUPTION                                             │
└─────────────────────────────────────────────────────────┘

Filesystem Support

┌─────────────────────────────────────────────────────────┐
│  ext4:  shrink offline ✅                               │
│  XFS:   shrink ❌ (grow-only)                           │
│  Btrfs: shrink online ✅                                │
│  swap:  no filesystem, use mkswap                       │
└─────────────────────────────────────────────────────────┘

The Snapshot Constraint

┌─────────────────────────────────────────────────────────┐
│  LV: lv_app                                             │
│  Snapshot: lv_app_snap (origin: lv_app)                 │
│         │                                               │
│         ▼  lvreduce lv_app                              │
│  FAILS: snapshot exists                                 │
│         │                                               │
│         ▼  lvremove lv_app_snap                         │
│  Retry lvreduce                                         │
└─────────────────────────────────────────────────────────┘

Summary

Item	Value
Shrink support	ext4 only (offline), not XFS
Sequence	`umount` → `e2fsck` → `resize2fs` → `lvreduce`
`lvreduce`	Reduces the block device
`resize2fs`	Shrinks the filesystem
Order	Filesystem first, LV second
Snapshot	Must be removed before reduction
Swap	`swapoff` → `lvreduce` → `mkswap` → `swapon`
XFS alternative	Backup, recreate, restore

Key takeaways:

The filesystem must shrink first. lvreduce removes extents without knowing what the filesystem is using. If the filesystem still owns those extents, the reduction corrupts it .
ext4 shrinks offline; XFS cannot shrink at all. The reduction workflow applies to ext4. XFS is grow-only, and the only way to reduce it is to back up, recreate, and restore .
The -r flag on lvreduce performs both steps. lvreduce -r -L 4G /dev/vg/lv calls the filesystem resize tool as part of the operation . For ext4, this is the one-command form.
Snapshots prevent reduction. An LV with a snapshot cannot be reduced until the snapshot is removed .
Swap has no filesystem. The reduction sequence for swap is swapoff, lvreduce, mkswap, swapon .
Verification is mandatory. lvs shows the LV size, df -h shows the filesystem size, and the filesystem must be smaller than or equal to the LV.

Remember: Reducing an LVM volume is the inverse of extending it, but the order is reversed for a reason. Extension grows the block device first because the filesystem can be told to use more space at any time. Reduction shrinks the filesystem first because the extents being removed must already be free. The lvreduce command does not check; it removes what it is told to remove. The discipline is the sequence: unmount, check, shrink the filesystem, reduce the LV, verify. XFS cannot participate in this sequence at all.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!