[linux-lvm] Corrupted LV after resize2fs crashed when adding new disk to LV
daytooner at gmail.com
Thu Oct 8 18:42:43 UTC 2009
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
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
The last command - resize2fs - crashed before completing.
- 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
- 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
FWIW, I did try running e2fsck with other superblocks, with this result:
"[root at 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the linux-lvm