linux-ext4 - Re: recovering from backup superblock with uninit

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]

Date:	Tue, 14 Jun 2011 11:53:31 +0300
From:	Amir Goldstein <amir73il@...il.com>
To:	Andreas Dilger <adilger@...ger.ca>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: recovering from backup superblock with uninit_bg

On Tue, Jun 14, 2011 at 11:35 AM, Andreas Dilger <adilger@...ger.ca> wrote:
> On 2011-06-14, at 2:15 AM, Amir Goldstein wrote:
>> Can you help me figure this one out.
>>
>> When I run the test:
>> # mkfs.ext4 /dev/sda5
>> # fsck.ext4 -nf -b 32768 /dev/sda5
>>
>> The results are a total chaos.
>>
>> Apparently, when opening an fs from a backup superblock,
>> all _UNINIT flags are cleared:
>>
>> First fsck rightfully complains that the group desc checksums are wrong.
>> Then, is complains about many errors in phantom inodes, because the inode
>> bitmap and tables are treated as initialized, but they aren't (see snip below)
>>
>> Any idea what was the purpose of clearing the _UNINIT flags?
>> Or how and if this should be fixed?
>
> The reason that the _UNINIT flags are cleared is that they cannot possibly
> be correct in the backup superblocks, and it is far more reliable to check
> all of the inode table blocks for inodes, as old e2fsck used to do.

Right, so in this case do the checksums need to be wrong by design?

>
> However, you shouldn't have garbage data in your inode table in the first
> place.  mke2fs will normally do the inode table zeroing, unless it detects
> that the kernel supports the "lazyinit zeroing thread".  At that point, it
> expects the kernel to proceed to zero all of the unused blocks in the
> filesystem at mount time.  If this isn't happening, it is a bug.
>

The test was: mkfs; fsck.
There was no mount in between.
I am testing a 16TB fs on a loop device, so I am mounting with -o noinit_itable,
so my image file won't grow.
I may as well pick up your patch to skip zeroing of the journal,
as that is mainly what my image file contains now.

Thanks,
Amir.
--
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