Re: Recovery after mkfs.ext4 on a ext4

[Theodore Ts'o <tytso@mit.edu>]

On Sun, Jun 15, 2014 at 10:27:08PM +0200, Killian De Volder wrote:
> >> Can e2fsck recover the directory structure and/or files in this scenario?
> > Well, maybe.  The problem is what got destroyed....  given some of the
> > errors you have described, it looks like more than the inode table got
> > wiped.  It's quite possible that version of mke2fs used to create the
> > original file system is older than the one used in the guest OS.  For
> > example, we changed where we placed the journal at one point.  That
> > would explain some of the file system errors.
> I assume this includes changing the journal size manually? (For the wiki.)

Yes, indeed.  Or any of the other mke2fs parameters.  This includes if
the file system was originally formated for ext3, and then was
upgraded to ext4, for example.  The size of the inode table, certain
file system features, etc., all can change the layout of where the
file system metadata gets placed.

All of these caveats apply for mke2fs -S as well, by the way.  The
mke2fs -S command basically reconstructs the superblock and block
group descriptors, and then exits afterwards, before celaring the
inode table.  It's unknown exactly how many of the disk blocks written
by your mke2fs running the guest OS actually made it to the disk, but
mercifully, the block group descriptors generally don't get written
out until after the inode table is cleared.  But that's one of the
reasons why I suggested that running mke2fs -S probably isn't going to
help.

> Sometimes I think it's certain inodes causing the excessive memory usage cause.
> 20GiB sounds a lot when the normal -f fschk took less then 3GiB. (It's a 16TiB file system).
> But suppose it needs more binary maps when the filesystem is this corrupt ?

E2fsck needs a lot more memory when dealing with a file systems where
some blocks are claimed by multiple inodes.  This is when pass
1b/1c/1d are invoked.  The e2fsck program also caches where the
directory blocks are located, but I doubt that's a particular concern
here.

> I've also been pondering about taking a lvm snapshot and running an
> actual repair.  (Instead of a testrun.) But I have no idea howbig
> the snapshot should be. Any indicators ?  > Good luck, Thank you for
> the info and luck, I'll need it :) > - Ted

Sorry, no clue.  It really depends on how badly damaged the file
system might be.

Something that could in theory be done is a modified version of e2fsck
that does not try to repair all file system corruption, but just
enough so that orphaned directories are mapped into lost+found, and
inodes that are so badly corrupted that it would cause the kernel
really complain are made inaccessible.  This would just be enough so
that the file system could be mounted read-only, or accessed via
debugfs's rdump, for data recovery purposes.

Unfortunately, I don't have time to implement such a best, but maybe
it's mode that could be added at some point in the future.

Regards,

						- Ted