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]

Message-Id: <BD0B2BAC-D0BF-44D6-AE26-988095078D3D@dilger.ca>
Date:	Wed, 28 Mar 2012 10:08:39 -0600
From:	Andreas Dilger <aedilger@...il.com>
To:	Yongqiang Yang <xiaoqiangnk@...il.com>
Cc:	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-03-27, at 8:47 AM, Yongqiang Yang wrote:
> Hi Ted, Andreas and List,
> 
> As Andreas pointed out last year, if the last group is the 1st group
> in a meta bg, then its group desc has no backup.
> With meta_bg resizing inode is useless,  I had a thought that we store
> a backup group descriptor of the last group in the resizing inode？
> What's your opinions?

The main difficulty of referencing a backup group descriptor from the
resize inode is that it may confuse tools that are trying to modify
the resize inode.  Also, it is more difficult to access the block from
userspace, since it would need to read the inode and use an extent to
reference the block beyond 16TB.

What about storing the 64-bit block number in the superblock?  This
should be safe for older e2fsprogs that understand META_BG.  At worst
the new backup group descriptor will not be updated on a resize by
older e2fsprogs, which is no worse than not having a backup at all.

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...

Actually, if the backup is always stored in the last block of the 0th
group (which is itself the last group in the filesystem), there isn't
even a need to store this location in the superblock.

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