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.
If the answer to the above is "yes" I'll respond with more specific
details if required.
Thanks,
David.
On 2012-07-21, at 1:49, David Hayes <[email protected]> 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
On 22/07/2012, Andreas Dilger <[email protected]> wrote:
> On 2012-07-21, at 1:49, David Hayes <[email protected]> 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
Thanks for the reply Andreas. Unfortunately the filesystem was mounted
after it was made and some data written to it. Also I mounted it at
least once subsequently, as that would have been the first time I
found the wrong partition had been used. Does that mean that there is
no chance of recovering the old filesystem? If so I will just focus on
forensic recovery of the files.
It looks like the kernel was 2.6.32-220.el6.i686. Is that new enough
so that the old inode tables would not be zeroed?
Thanks for your help.
Regards, David.
On 2012-07-21, at 15:20, David Hayes <[email protected]> wrote:
> On 22/07/2012, Andreas Dilger <[email protected]> wrote:
>> On 2012-07-21, at 1:49, David Hayes <[email protected]> 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
>
> Thanks for the reply Andreas. Unfortunately the filesystem was mounted
> after it was made and some data written to it. Also I mounted it at
> least once subsequently, as that would have been the first time I
> found the wrong partition had been used. Does that mean that there is
> no chance of recovering the old filesystem? If so I will just focus on
> forensic recovery of the files.
>
> It looks like the kernel was 2.6.32-220.el6.i686. Is that new enough
> so that the old inode tables would not be zeroed?
If it was mounted and used, it doesn't matter what kernel was used - the inode table would have been zeroed after mount. That means the inode table was zeroed.
The only possible saving grace is that ext4 may have put the inode tables in a different location. Probably at this stage, you could try ext3grep, which will scan the disk for metadata, and may be able to recover whatever chunks of the filesystem are still in place.
Cheers, Andreas