linux-ext4 - Re: How to recover a damaged ext4 file system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090107214148.GA3151@moongate.localnet>
Date:	Wed, 7 Jan 2009 22:42:06 +0100
From:	Christian Ohm <chr.ohm@....net>
To:	Theodore Tso <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: How to recover a damaged ext4 file system?

On Tuesday,  6 January 2009 at 14:34, Theodore Tso wrote:
> On Tue, Jan 06, 2009 at 05:05:27AM -0700, Andreas Dilger wrote:
> > 
> > You should try to run e2fsck with the backup group descriptors, using
> > the -B and/or -b options (at a guess -B 4096 and -b 32768).
> 
> That probably won't help, given that the fsck transcript already says
> this:
> 
> > > fsck.ext4: Group descriptors look bad... trying backup blocks...

Yes, I think I tried that without success.

> It looks like both the primary and the backup block group descriptors
> are bad.  I'm not sure how this happened; normally nothing touches the
> backup block superblocks at all.  Stupid question --- are you sure the
> partition table is sane; that's always the first thing to check.

I think so; I didn't explicitly look, but didn't notice anything strange.

> Can you upload someplace the output of
> 
> dumpe2fs /dev/XXX
> dumpe2fs -o superblock=32768 /dev/XXX
> dumpe2fs -o superblock=98304 /dev/XXX
> 
> That would be helpful to see what had happened.

I'll do that soon; I got another harddisk to copy the partition, but both disks
aren't connected right now. 

> > 2. Is this corruption a fault of ext4? I guess this is difficult to
> > answer, but I had ext3 survive any lockups without much problems. So
> > far ext4 seems not quite that robust, but perhaps another file
> > system would have blown up as well in this situation. Is there any
> > information I can give you to help make ext4 more robust?
> 
> I'm not sure what the hard system hang did, but it looks like it
> splattered a lot of random crap all over the harddrive.  I doubt ext4
> did this, and I doubt ext3 would have done any better.... we need to
> know a lot more about exactly what sort damage was done to the
> filesytem to say for certain, though.

I did one copy of the partition already (took three hours, so not something to
do often...), and ran fsck -y on that. The result was an endless fsck loop like
that described in
http://www.linuxquestions.org/questions/linux-hardware-18/corrupt-ext3-partition-need-to-recover-376366/.
Oh, and I have to try if dumpe2fs actually works, either that or debugfs failed
when I tried to run it on the original disk (I also ran dumpe2fs on the copy
while fsck was doing its looping, and depending on the time it did or did not
find a file system on the device). Anyway, I hope I can experiment some more
tomorrow.

Oh, and is there a human understandable description of the on-disk data format
to compare with a hexdump? A (admittedly very short) search didn't turn up
anything.

Best regards,
Christian Ohm

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html