Reducing LVM Volumes

Reducing LVM Volumes

Reducing an LVM logical volume is the reverse of extending — you shrink the LV to reclaim space for other uses. It is significantly more dangerous than extending because it involves shrinking the file system first: if you shrink the LV smaller than the data it contains, the file system is corrupted. This is why the XFS file system cannot be shrunk at all, and ext4 reduction requires multiple careful steps on an unmounted volume.

Why reducing is risky

SAFE order (shrink, then reduce LV):
  FS: [====data====|====free space====]   200 GB ext4
  1. resize2fs to 100 GB (shrinks FS within LV)
  FS: [====data====|free|//not used//]   100 GB used, rest unused
  2. lvreduce to 100 GB (shrinks LV to match FS)
  LV: [100 GB LV  ]                      OK!

DANGEROUS order (reduce LV first, then FS):
  LV: [100 GB LV  ]   ← Reduced LV, FS still thinks it's 200 GB
  FS: [====data====|CORRUPTED]           ext4 tries to access blocks outside LV
  Result: FILE SYSTEM CORRUPTION

Shrinking an ext4 logical volume

⚠️ WARNING: Never shrink an LV that is currently mounted and in use. The file system MUST be unmounted before running resize2fs to shrink it. Shrinking a mounted file system corrupts it. Have a backup before attempting any LV reduction.

# Step 1: Unmount the logical volume
sudo umount /data

# Step 2: Check the file system (required before resizing)
sudo fsck -f /dev/vg_data/data

# Step 3: Shrink the ext4 file system
# Shrink to 100 GB (leave some buffer — resize to 95 GB if you want 100 GB LV)
sudo resize2fs /dev/vg_data/data 95G

resize2fs shrink output

resize2fs 1.46.5 (30-Dec-2021)
Resizing the filesystem on /dev/vg_data/data to 24903680 (4k) blocks.
The filesystem on /dev/vg_data/data is now 24903680 (4k) blocks long.

# Step 4: Shrink the logical volume (AFTER the FS is already smaller)
sudo lvreduce -L 100G /dev/vg_data/data

lvreduce output

  WARNING: Reducing active logical volume to 100.00 GiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
  Do you really want to reduce vg_data/data? [y/n]: y
  Size of logical volume vg_data/data changed from 200.00 GiB to 100.00 GiB.
  Logical volume vg_data/data successfully resized.

# Step 5: Grow the file system to fill the new LV size (FS was at 95G, LV at 100G)
sudo resize2fs /dev/vg_data/data    # No size = fill the entire LV

# Step 6: Mount and verify
sudo mount /dev/vg_data/data /data
df -h /data    # Should now show ~100G

XFS cannot shrink

# XFS does NOT support shrinking — this will fail:
sudo xfs_growfs -D 51200000 /data    # Can only grow, cannot shrink

# Workaround if you need to reduce an XFS volume:
# 1. Back up all data
sudo rsync -av /data/ /backup/data-$(date +%Y%m%d)/

# 2. Unmount, reformat with the smaller size
sudo umount /data
sudo lvreduce -L 100G /dev/vg_data/data    # Reduce LV (data was backed up)
sudo mkfs.xfs /dev/vg_data/data            # Reformat

# 3. Restore data
sudo mount /dev/vg_data/data /data
sudo rsync -av /backup/data-20240601/ /data/

Moving data between logical volumes

# Alternative to shrinking: move data to a new, smaller LV
# Useful when you want to change file system type too

# 1. Create a new smaller LV
sudo lvcreate -n data-new -L 100G vg_data
sudo mkfs.xfs /dev/vg_data/data-new

# 2. Copy data (rsync preserves permissions, ownership)
sudo mount /dev/vg_data/data-new /mnt/newdata
sudo rsync -av /data/ /mnt/newdata/

# 3. Swap mount points (requires brief downtime)
sudo umount /data /mnt/newdata
sudo mount /dev/vg_data/data-new /data

# 4. Update /etc/fstab to use the new LV

# 5. Remove old LV after verifying data is intact
sudo lvremove /dev/vg_data/data

Conclusion

LV reduction is a high-risk operation. Always: unmount first, run fsck -f before resize, shrink the file system before the LV (never the other way around), and have a backup. For XFS, there is no shrink — only backup, reformat, and restore. On production systems, consider whether moving data to a new LV is safer and more practical than trying to shrink in place. The extra disk space used during transition is cheaper than recovering from a corrupted file system.