Shrinking an LV - the highest-risk LVM operation · Linux

Growing an LV is routine. Shrinking one is not. Growing is forgiving: the filesystem simply has not caught up yet. Shrinking is unforgiving: the moment the LV is smaller than the filesystem, the filesystem is referencing blocks that no longer exist. That is not a degraded filesystem. That is a destroyed one.

This lesson covers the only two safe ways to reclaim space, and the one filesystem where neither of them works.

Gate 1: what filesystem is on the LV?

Never start a shrink from the LVM side. Start from the filesystem side, because the filesystem decides whether the operation is possible at all.

Read-only / Safeidentify the filesystem— FSTYPE is the gate. ext2, ext3, and ext4 can shrink offline. XFS cannot shrink at all, at any size, online or offline. Btrfs can shrink online with btrfs filesystem resize.

$ lsblk -f /dev/vg0/data; df -h /data

NAME       FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
vg0-data   ext4   1.0         6f1c4c2a-9d31-4a6e-b0b2-0c9a1f2e77aa     63G    31% /data
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg0-data  98G   29G   63G  32% /data

Gate 2: does the data fit?

df reports the used space, but the used space is not the floor. Shrink to the minimum and you have a full filesystem the moment anything is written. Work out the target from the used size plus real headroom, not from what you would like to reclaim.

Read-only / Safeminimum size— -P prints the estimated minimum size in filesystem blocks, without changing anything. Multiply by the block size (usually 4096) to get bytes. Treat this as the absolute floor and never target it.

$ resize2fs -P /dev/vg0/data

resize2fs 1.47.0 (5-Feb-2023)
Estimated minimum size of the filesystem: 7602176

The ext4 procedure, in strict order

The order is the lesson. Filesystem first, LV second. Extending runs the other way round, which is exactly why people get this wrong under pressure.

Take a backup, and verify the backup restores. Shrink has no undo.
Unmount the filesystem. ext4 cannot shrink online.
Run e2fsck -f. resize2fs refuses to shrink an unchecked filesystem.
Shrink the FILESYSTEM to the target, with margin: resize2fs /dev/vg0/data 40G
Shrink the LV to a size LARGER than the filesystem: lvreduce -L 45G /dev/vg0/data
Grow the filesystem back out to fill the LV: resize2fs /dev/vg0/data
Mount and verify: mount /data; df -h /data

Data-loss riskfilesystem first— e2fsck -f is mandatory, not advisory: resize2fs exits with 'Please run e2fsck -f first' otherwise. The 40G target is deliberately below the 45G the LV will become, so the LV is never smaller than the filesystem at any point.

# umount /data && e2fsck -f /dev/vg0/data && resize2fs /dev/vg0/data 40G

e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vg0/data: 41231/6553600 files (0.2% non-contiguous), 7602176/25690112 blocks
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/vg0/data to 10485760 (4k) blocks.
The filesystem on /dev/vg0/data is now 10485760 (4k) blocks long.

Illustrative output

Data-loss riskLV second, and larger— 45G is larger than the 40G filesystem. That 5G gap is the safety margin that absorbs rounding: LVM rounds to whole extents, resize2fs rounds to whole blocks, and the two do not round the same way.

# lvreduce -L 45G /dev/vg0/data

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

Illustrative output

Configuration changereclaim the margin— With no size argument resize2fs grows the filesystem to fill the device. This reclaims the 5G safety margin after the risky step is over. Skipping this step is safe; skipping the margin is not.

# resize2fs /dev/vg0/data && mount /data && df -h /data

resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/vg0/data to 11796480 (4k) blocks.
The filesystem on /dev/vg0/data is now 11796480 (4k) blocks long.
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg0-data   44G   29G   14G  68% /data

Illustrative output

The safer alternative: let LVM drive

Modern LVM can drive the filesystem resize itself. -r (also spelled --resizefs, and equivalent to --fs resize) hands the unmount, check, and resize to fsadm, which knows the correct order and refuses filesystems it cannot shrink.

Data-loss risklvreduce -r— With -r, fsadm unmounts if needed, runs the check, shrinks the filesystem, and only then shrinks the LV. Use --fsmode manage to have it restore the original mount state, or --fsmode nochange to make it fail rather than unmount a busy filesystem.

# lvreduce -r -L 45G /dev/vg0/data

fsck from util-linux 2.39.3
/dev/mapper/vg0-data: clean, 41231/6553600 files, 7602176/25690112 blocks
fsadm: Resizing filesystem ext4 on device /dev/mapper/vg0-data to 48318382080 bytes
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/mapper/vg0-data to 11796480 (4k) blocks.
Size of logical volume vg0/data changed from 98.00 GiB to 45.00 GiB.
Logical volume vg0/data successfully resized.

Illustrative output

Prefer -r for routine work. Keep the manual sequence in your head anyway, because -r is what you cannot use when the filesystem is on a device fsadm does not recognise, when the LV is a snapshot origin mid-merge, or when you are recovering a shrink that was already done in the wrong order.

What going the wrong way round looks like

An operator runs lvreduce -L 45G on a 98 GiB LV whose ext4 filesystem is still 98 GiB. LVM reports success. The filesystem stays mounted and appears fine, because the metadata it needs is near the start of the device. Hours later a write lands on a block past 45 GiB, the kernel logs an I/O error, ext4 flips the filesystem read-only, and the service stops. e2fsck now finds tens of thousands of blocks past the end of the device. The recovery is a restore from backup, not a repair.

That is the whole reason the order is filesystem first: the filesystem is the only component that knows which blocks are in use, so it must be the one to give them up.

Gate 1: what filesystem is on the LV?

Gate 2: does the data fit?

The ext4 procedure, in strict order

The safer alternative: let LVM drive

What going the wrong way round looks like

Knowledge check