[long] major problems on fs; e2fsck running out of memory
tytso at mit.edu
Mon Jun 2 11:30:25 UTC 2014
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
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.
More information about the Ext3-users