I used parted to resize (shrink) an ext3 filesystem and associated
partition, and it buggered my system. The operation completed
apparently successfully, reporting no errors, but after reboot, the fs
wouldn't mount, being marked as having errors, and and e2fsck said
"The filesystem size (according to the superblock) is xxx blocks
The physical size of the device is xxx blocks Either the superblock or
the partition table is likely to be corrupt!". So the fs still thought
it was its original size (larger than its partition).
At this point, the fs would actually mount without errors if I mounted
it manually (ro), and all my data seemed intact, it just thought it
had way more free space than it should have, and it couldn't complete
an fsck (and was obviously not safe to use mounted rw lest it try to
write to space it didn't actually own). Google turned up some accounts
of people with the identical issue, and suggestions to fix it by
writing a new superblock with e2sck -S, then fscking - I did this, and
it totally trashed my filesystem. The fs is now the right size and
mounts fine, but everything just got dumped into lost+found.
Is there any way I can fix this and get my data back? At least get it
back to its previous state so I can mount it ro and copy my data off?
Is my old superblock backed up somewhere, or does e2fsk update the
backup superblock as well? Would my old superblock even help, or did
the fsck trash my inode structure?
Currently I think I have all my data, just dumped in lost+found
without filenames - is there any way to salvage anything from that?
And is this a known bug in ext2resize? In parted?
--
Kevin Bowen
kevin at ucsd.edu
