LVM logical volume partition corrupted after lvreduce

lvmpartition

I encounter the problem when I try to shrink one logical volume. I took the actions as following steps shown below:

# unmount /home
# lvreduce --size -100G /dev/vg_dev/lv_home 
# lvdisplay /dev/vg_dev/lv_home 

--- Logical volume ---
LV Path                /dev/vg_dev/lv_home
LV Name                lv_home
VG Name                vg_dev
LV UUID                QOxrP3-nS36-nZTG-yL7e-sDi0-Wl9z-LXp4pJ
LV Write Access        read/write
LV Creation host, time , 
LV Status              available
# open                 1
LV Size                197.98 GiB
Current LE             50683
Segments               1
Allocation             inherit
Read ahead sectors     auto
- currently set to     256
Block device           253:4

# e2fsck -f /dev/vg_dev/lv_home

e2fsck 1.41.12 (17-May-2010)
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!
Abort<y>?

# resize2fs /dev/vg_dev/lv_home

resize2fs 1.41.12 (17-May-2010)
Please run 'e2fsck -f /dev/vg_dev/lv_home' first.

Picture of console.

I cannot mount the logical volume at all, can someone help me solve this problem?

Best Answer

It sounds like you've tried to resize a volume and filesystem in the wrong order.

When shrinking, you should perform actions in this order

  1. Resize the file system
  2. Resize the logical volume

When growing, you should perform actions in this order

  1. Resize the logical volume
  2. Resize the file system

For your issue

The first thing I would do is clone the entire drive using dd to a spare drive, and work on this one for recovery.

If you are lucky and you didn't use any of the LV available extents and thus the blocks on the disk haven't changed, you might be able to resize the LV back to what it was previously, then attempt a fsck on the file system. If the fsck passes, you can then resize the file system.

If you still get an error with the fsck you might have done irreparable damage.

NB

lvresize now supports file system resize when passing an additional argument -r|--resizefs which mitigates the need to resize in a particular order and drastically reduces the potential for error.