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@xxxxxxxx _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
