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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <12869D43-E068-4F4B-9A06-D0A35DA5CB40@whamcloud.com>
Date:	Sat, 21 Jul 2012 09:17:34 -0700
From:	Andreas Dilger <adilger@...mcloud.com>
To:	David Hayes <davemellow@...il.com>
Cc:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: restoring ext3 filesystem overwritten by ext4

On 2012-07-21, at 1:49, David Hayes <davemellow@...il.com> wrote:

> This is a general question about whether it should be possible to
> effectively undo a mkfs.ext4 on a partition which previously held an
> ext3 filesystem. I'm just a user, not a developer, so I'm not familiar
> with the details of where backup superblocks get written etc. I had no
> luck finding any old filesystem information with testdisk, so I'm
> wondering whether ext4 might overwrite all the superblocks by
> coincidence of choosing the same blocks in the partition to write them
> as mkfs.ext3 did, or something.

Yes, though it is no coincidence. For the same filesystem size, the same superblocks will be used. It is likely that different group descriptor blocks would be used, because of flex_bg. If you have a newer kernel it is possible the inode tables were not zeroed out, which would otherwise have clobbered a large part of the data. 

> If the answer to the above is "yes" I'll respond with more specific
> details if required.


First thing - do NOT mount the filesystem. Make a copy of the whole partition using "dd" for experimentation.  If the ext4 filesystem has never been mounted, there is at least some chance the data can be recovered. 

Unfortunately, the new group descriptors will be in the same place as the old ones. It is necessary to do something like "mke2fs -t ext3 -S" to rebuild the old group descriptors and then run "e2fsck -fy" to see if there is anything in the inode tables to recover. 

Cheers, Andreas--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ