When I attempted to shrink my 300GB /home partition by 100GB using lvreduce, the operation completed without errors but left me with a corrupted filesystem that couldn't be mounted. The key symptom was the mismatch between filesystem blocks (78,113,792) and physical device blocks (51,899,392) reported by e2fsck.

First, verify the current state of your logical volume:

sudo lvdisplay /dev/vg_dev/lv_home
sudo file -s /dev/vg_dev/lv_home
sudo blkid /dev/vg_dev/lv_home

The critical error appears when checking the filesystem:

sudo e2fsck -f /dev/vg_dev/lv_home
# Output shows superblock/partition table corruption
# Physical size smaller than filesystem size

Here's the step-by-step recovery process:

# 1. First attempt to repair superblocks
sudo e2fsck -b 32768 /dev/vg_dev/lv_home  # Backup superblock location
# If that fails...

# 2. Force filesystem size adjustment
sudo e2fsck -f -y /dev/vg_dev/lv_home
sudo resize2fs /dev/vg_dev/lv_home

# 3. Alternative when standard resize fails
sudo e2fsck -f -c -D -y /dev/vg_dev/lv_home
sudo resize2fs /dev/vg_dev/lv_home 51900M  # Slightly under new LV size

Always follow this sequence when shrinking LVM volumes:

# Safe reduction procedure:
1. umount /dev/vg_dev/lv_home
2. e2fsck -f /dev/vg_dev/lv_home
3. resize2fs /dev/vg_dev/lv_home NEW_SIZE
4. lvreduce -L NEW_SIZE /dev/vg_dev/lv_home
5. mount /dev/vg_dev/lv_home

For severe corruption cases:

# Create raw image for safer recovery attempts
sudo dd if=/dev/vg_dev/lv_home of=home_recovery.img bs=1M conv=noerror,sync

# Use advanced tools like testdisk or extundelete
sudo extundelete /dev/vg_dev/lv_home --restore-all
sudo debugfs /dev/vg_dev/lv_home

• Always shrink filesystem before LVM volume
• Maintain backup superblocks with dumpe2fs
• Consider using --resizefs flag with modern LVM versions
• For critical data, snapshot before resizing

---

When attempting to shrink an LVM logical volume containing an ext4 filesystem, I executed these commands in order:

umount /home
lvreduce --size -100G /dev/vg_dev/lv_home
e2fsck -f /dev/vg_dev/lv_home

The e2fsck output reveals the core issue:

The filesystem size (according to the superblock) is 78113792 blocks
The physical size of the device is 51899392 blocks
Either the superblock or the partition table is likely to be corrupt!

This occurs because we reduced the physical volume size before resizing the filesystem. The correct order should be:

1. Unmount filesystem
2. Run filesystem check
3. Shrink filesystem first (resize2fs)
4. Then reduce LV size (lvreduce)

Here's how to recover the corrupted LV:

Step 1: Restore Original LV Size

lvextend -L +100G /dev/vg_dev/lv_home

Step 2: Force Filesystem Check

e2fsck -f -y /dev/vg_dev/lv_home

Step 3: Proper Resizing Sequence

# First shrink filesystem with extra safety margin
resize2fs /dev/vg_dev/lv_home 180G

# Now reduce the LV
lvreduce -L 180G /dev/vg_dev/lv_home

# Final filesystem resize to fill space
resize2fs /dev/vg_dev/lv_home

If the above fails, try these advanced techniques:

Using Backup Superblocks

mkfs.ext4 -n /dev/vg_dev/lv_home  # Show superblock locations
e2fsck -b 32768 /dev/vg_dev/lv_home  # Use alternate superblock

For XFS Filesystems

xfs_repair /dev/vg_dev/lv_home
xfs_growfs /mount/point

Always follow this safe workflow for LVM reductions:

1. umount /filesystem
2. e2fsck -f /dev/vg/lv
3. resize2fs /dev/vg/lv NEW_SIZE
4. lvreduce -L NEW_SIZE /dev/vg/lv
5. mount /filesystem

Create this bash script for future operations:

#!/bin/bash
VG=$1
LV=$2
SIZE=$3
MOUNTPOINT=$4

umount $MOUNTPOINT
e2fsck -f /dev/$VG/$LV
resize2fs /dev/$VG/$LV $SIZE
lvreduce -L $SIZE /dev/$VG/$LV
mount $MOUNTPOINT