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.
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
When growing, you should perform actions in this order
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 thefsck
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.