On Sun, Jun 01, 2014 at 08:54:24PM -0700, Keith Keller wrote: > > Heh, I like your understatement. :) I think this helps answer part of > my questions in my second email: I should probably try to preserve > changes from last backup before getting too deep into a tricky e2fsck. > At one point the fs was still mountable, so I could have tried to copy > files off first. (In a physical failure scenario it's exactly what I'd > have done, but I wasn't thinking of that in this case.) Yeah, it would have been nice to have preserved the outputs from earlier e2fsck runs just so we could see what e2fsck did that apparently ended up overwriting parts of the block group descriptors. It might be possible to read the block group descriptors associated with one of the backup superblocks to find the portion of the inode table associated with inode #2. (i.e., try using "debugfs -s 32768 /dev/dm0"). One of the things that might have detected the problem sooner, and perhaps allowed you to recover more smoothly, would be to try running e2fsck immediately after running resize2fs. With the vintage kernel and e2fsprogs shipping with the version of CentOS you are apparently using, online resizing is probably safer than off-line --- although if you are using the 1.42.10 version of resize2fs and the 2.6.32 based kernel, I'd probably sugges off-line resizes as being more safe. And either way, running e2fsck on the file system after the resize is probably a good idea. > My hunch is that it would take a large and lucky effort to try to get > anything useful off this fs. Does that seem like a reasonable guess? I'd try using the backup superblock approach, but if that doesn't work, yes, that's probably a reasonable conclusion. Regards, - Ted _______________________________________________ Ext3-users mailing list Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
