linux-ext4 - Re: backup of the last group'descriptor when it is the 1st group of a meta

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:	Sun, 1 Apr 2012 23:46:06 -0600
From:	Andreas Dilger <aedilger@...il.com>
To:	Yongqiang Yang <xiaoqiangnk@...il.com>
Cc:	Andreas Dilger <aedilger@...il.com>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	"Ted Ts'o" <tytso@....edu>
Subject: Re: backup of the last group'descriptor when it is the 1st group of a meta_bg

On 2012-04-01, at 11:04 PM, Yongqiang Yang wrote:
> On Thu, Mar 29, 2012 at 12:08 AM, Andreas Dilger <aedilger@...il.com> wrote:
>> I would suggest to put the backup group descriptor in the last block
>> of the filesystem.  This would be in the 0th group of the metagroup.
>> If the metagroup grows to have a second group, then this block is not
>> needed anymore, and if both the primary (at the beginning of the group)
>> and the backup (at the end of the group) are corrupted, then there is
>> little chance that the data in this last group is good either...
> 
> Now we have 2 solutions, the 1st one is storing backup group
> descriptor in resize inode itself while the 2nd one is storing backup
> in the last block of the 0th block. Both need patching e2fsck because
> older e2fsck does not work.  The 1st one's patch to e2fsck is much
> more complicated, because only one group descriptor is stored in
> resize inode itself, but the e2fsck's code reading/writing group
> descriptor block. so I like the 2nd one.

This solution doesn't _require_ patching e2fsck, which is useful.
If an older e2fsck doesn't understand the backup group descriptor is
in the last block, it is no worse than today where the backup does
not exist at all.  In that case, the old e2fsck would mark this block
free, and there is a tiny chance that it would be allocated to some
file and overwritten.

However, the last block will almost never be allocated, since block
allocation is typically biased toward the beginning of the disk, so
storing a checksum in it (per Darrick's patches) would allow a new
e2fsck to use it in case of emergency, and it would mark the block
in use again (so long as it wasn't allocated to some file).

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