LVM logical volume partition corrupted after lvreduce
Solution 1:
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
- Resize the file system
- Resize the logical volume
When growing, you should perform actions in this order
- Resize the logical volume
- 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.
Solution 2:
I resized my logical disc, /dev/mapper and I got the error:
Either the superblock or the partition table is likely to be corrupt!
The solution was to make this order with the corrupt partition:
[root@localhost]# mke2fs /dev/mapper/VolGroup-lv_home && fsck /dev/mapper/VolGroup-lv_home
and that's all.
source: Size in superblock is different from the physical size of the partition
Solution 3:
One possible solution is to extend the filesystem by 100GB, but there may be some data loss. Please take the backup of the desired filesystem.
# lvextend -L +100G /dev/vg_dev/lv_home
# resize2fs /dev/vg_dev/lv_home
Then you can mount the filesytem.
Hope this would solve your issue.