Re: Recovery after mkfs.ext4 on a ext4

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

On Sun, Jun 15, 2014 at 10:12:14AM +0200, Killian De Volder wrote:
> Excuse me for requesting this information,
> but I could not find any good leads on how to deal with this issue.
> Any help would be appreciated.
> 
> This is what happened:
> I accidentally exported the wrong block-device to a virtual machine.
> I ran mkfs.ext4 on this, already mounted ext4, block-device.
> As soon as I noticed the error,I stopped it.
> It got to "Writing superblocks and file system accounting information".
> (After Writing inode tables, and creating journal).

Ouch.  There are safety measures to prevent mke2fs from running on a
mounted file system.  However, these don't apply when you've exported
the block device via KVM.  It could be perhaps argued that qemu should
add this safety check, and at least warn before you exported a block
device already in use as a file system.  It's probably worth taking
that up with the qemu folks.

If it's any consolation the very latest version of e2fsprogs has a
safety check that might have caught the problem:

# mke2fs -t ext4 /dev/heap/scratch
mke2fs 1.42.10 (18-May-2014)
/dev/heap/scratch contains a ext4 file system labelled 'Important Stuff'
		  last mounted on Tue Jun  3 16:12:01 2014
Proceed anyway? (y,n) n

> Would it be better if I ran mkfs.ext4 -S ?

Probably note.  This is useful when the superblock and block group
descriptors have been destroyed, and that's not the case here.  The
fact that the volume name is the original means that you have at least
the original superblock, and the real problem here is that damage that
was caused by the portions of the inode table that were wiped out.  

> 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.

> Can I use debugfs to start at a directory inode and then use rdump ?

Again, maybe.  The problem is that if a particular subdirectory is
destroyed, then you won't find it via rdump.  E2fsck can relocate
files and subdirectories contained in damaged directories to
lost+found, which rdump obviously can't cope with.

> Should I just revert to file recovery tools like photorec ?

Sorry, I keep saying maybe.  Photorec will definitely recover more
files; however, you won't have the filename data, which may be quite
problematic.  If the files are self identifying via things like EXIF
tags, or MP3 tags, or other in-file metadata, then photorec works
really well. 

But if you are stiching together lots of small source files, or
component .tex files from several dozen different directories, it's
photorec may not be that much more useful.

> Is there a way to reduce the memory usage during e2fsck in this scenario ?

Sorry, not really.

Good luck,

						- Ted