Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

# 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?

share|improve this question
add comment

1 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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.