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: <E51F9800-231C-45E0-A013-9DC1749AA00C@dilger.ca>
Date:	Tue, 14 Jun 2011 02:35:51 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: recovering from backup superblock with uninit_bg

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.

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.


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