SysTutorials

Safely Shrinking Ext4 Filesystems on LVM

· Eric Ma · updated April 11, 2026

Shrinking an ext4 filesystem on LVM is riskier than expanding—it requires the filesystem offline and careful size planning. The operation can take hours on large volumes, and mistakes can destroy data. This guide walks through the safe path with verification at each step.

Prerequisites

Before starting:

The Safe Shrink Procedure

Assume you have:

Step 1: Unmount the filesystem

umount /mnt/data

This is non-negotiable. Shrinking touches allocation metadata that the kernel actively manages on a mounted filesystem. Unmounting prevents corruption and ensures safe metadata writes.

Verify it’s unmounted:

lsblk | grep lv_data

Step 2: Run fsck before shrinking

Always check the filesystem before resize operations:

fsck.ext4 -f /dev/vg/lv_data

The -f flag forces a check even if the filesystem appears clean. Address any errors reported before proceeding.

Step 3: Shrink the filesystem and LV together

Use lvresize with --resizefs to handle both operations atomically:

lvresize --resizefs --size 200G /dev/vg/lv_data

The --resizefs flag is critical—it automatically runs resize2fs before shrinking the LV, preventing size mismatches that can corrupt the filesystem. Avoid running resize2fs and lvresize separately unless you have a specific reason.

Expected output:

fsck from util-linux 2.39.1
/dev/mapper/vg-lv_data: 1523/6553600 files (0.2% non-contiguous), 892145/26214400 blocks
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/mapper/vg-lv_data to 52428800 (4k) blocks.
Reducing logical volume lv_data to 200.00 GiB
Logical volume lv_data successfully resized

Don’t interrupt this. On a 500GB filesystem with heavy fragmentation, this can take 2–4 hours. Monitor progress in another terminal:

lvs -o lv_name,lv_size vg

Step 4: Remount and verify

mount /mnt/data
df -hT /mnt/data

Confirm the size and that the filesystem is readable. Check for any kernel errors in dmesg:

dmesg | tail -20

Run a second fsck to validate:

umount /mnt/data
fsck.ext4 -n /dev/vg/lv_data
mount /mnt/data

Freeing Space in the Volume Group

The space freed from shrinking the LV now belongs to the volume group:

vgs vg

You can allocate this to other LVs or leave it available for future growth.

Removing a Physical Volume (Optional)

If you’re decommissioning the disk entirely:

Move data off the PV

pvmove /dev/sdb1

This migrates all data from /dev/sdb1 to other PVs in vg. Check free space first:

vgs vg
lvs -o +devices vg

The move can take hours on large LVs. Don’t interrupt it.

Remove the PV from the VG

vgreduce vg /dev/sdb1
pvremove /dev/sdb1

The disk can now be physically removed or repurposed.

Shrinking the Partition (Optional)

If you want to reclaim raw disk space, shrink both the PV metadata and partition boundary.

Shrink the physical volume

pvresize --setphysicalvolumesize 650G /dev/sdb1

Verify:

pvs -o pv_name,pv_size

Shrink the partition boundary

With parted:

parted /dev/sdb
(parted) print
(parted) resizepart 1 650GB
(parted) quit

Confirm the kernel sees the change:

partprobe /dev/sdb
fdisk -l /dev/sdb | head -20

If partprobe fails silently, reboot to force partition table re-read.

For automated/scriptable shrinking, use parted in non-interactive mode:

parted -s /dev/sdb resizepart 1 650GB

For GPT partitions with strict alignment requirements, gdisk offers finer control:

gdisk /dev/sdb
# Command: p (print)
# Command: d (delete partition 1)
# Command: n (new partition, set end sector manually)
# Command: w (write and exit)

Final Verification

After all operations, validate the system state:

lvs -o lv_name,lv_size,lv_attr vg
pvs -o pv_name,pv_size
vgs vg
df -h /mnt/data

Run your workloads on the shrunken filesystem for at least 24 hours before removing the backup. Watch dmesg and system logs for any ext4-related warnings.

Common Failure Points

← All posts