Corrupted LV after resize2fs crashed when adding new disk to LV

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I've written several extensive posts about this problem to the fedora forum (software) with no real results -and FWIW, I am getting very desparate. I was referred here, or possibly post bug report.

The thread at Fedora Forums is >>click here<<.

Basically, this is the problem:

I have an ext4 filesystem in VolGroup3W-LogVol3W. Originally, it was 331G, and was working fine. e2fsck ran through without finding any problems.

Then I tried to add another disk (111G) to the LV. I created the PV (pvcreate), added it to the VG (vgextend). All this was okay. I then added this to the LV (lvextend) and then tried to resize the filesystem (resize2fs).

The last command - resize2fs - crashed before completing.

After that:

- vgdisplay showed a total 442G for VolGroup3W (the original size plus the new PV) - that's okay
- lvs showed a total of 331G for LogVol3W (the original size, without the new PV)
- mount failed, with "EXT4-fs: bad geometry: block count 102432768 exceeds size of device (86773760 blocks)" in dmesg
- e2fsck for the LV reports basically the same thing.

I removed the new diisk from the VG. I couldn't do lvreduce, since the LV didn't see the new PV space.

When I run e2fsck and answer 'n' to abort, I get 2648 Group checksum errors, and after answering 'y' to fix them, I get this:

"/dev/VolGroup3W/LogVol3W contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Error reading block 86802432 (Invalid argument) while getting next inode from scan.  Ignore error? no

Error while scanning inodes (21700608): Can't read next inode                 
e2fsck: aborted"

FWIW, I did try running e2fsck with other superblocks, with this result:

"[root@Elmer ~]# e2fsck -b 32768 /dev/VolGroup3W/LogVol3W
e2fsck 1.41.4 (27-Jan-2009)
/dev/VolGroup3W/LogVol3W: recovering journal
e2fsck: unable to set superblock flags on /dev/VolGroup3W/LogVol3W"


So it seems to me, IMHO, that the LVM is looking at one set of data, while the other utilities (eg, mount, e2fsck) are looking at another. I am assuming that the original LV data is still intact, just somewhere the file size/block count is wrong.(one place says the original size, the other sees the size with the new disk (attempted to be) added.

Is there ANY way possible to rectify this? PLEASE!!!

As I said, I am rather desparate to recover the data on the original LV (yes, I do know the value of backing up data :-( ). So any ideas will be greatly appreciated.

ken





_______________________________________________
linux-lvm mailing list
linux-lvm@redhat.com
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/

[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux