linux-ext4 - Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX

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] [day] [month] [year] [list]

Message-ID: <20080428120138.GE30840@mit.edu>
Date:	Mon, 28 Apr 2008 08:01:38 -0400
From:	Theodore Tso <tytso@....edu>
To:	Andreas Dilger <adilger@....com>
Cc:	"Jose R. Santos" <jrs@...ibm.com>, linux-ext4@...r.kernel.org,
	Valerie Clement <valerie.clement@...l.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation
	for FLEX_BG

On Fri, Apr 25, 2008 at 02:10:26PM -0600, Andreas Dilger wrote:
> I'd HOPE (and I believe this is what Ted's recent patch did) is that any
> group which is being used to store flexbg data will have an initialized
> block bitmap in it, because it is "non-standard".

Correct.  If there are *any* blocks allocated other than the block's
own metadata, BLOCK_UNINIT will never be set.  And that's precisely to
avoid the tricky case described in your next paragraph:

> What is more tricky is if a group has BLOCK_UNINIT and/or INODE_UNINIT
> set what should happen when that group's block bitmap is initialized.
> Should it assume there is a block + inode bitmap and an itable, or is
> it enough to check its own group descriptor to determine if the bitmap
> and itable are not in the group itself.

In the kernel, it should be enough only to check bg_inode_bitmp,
bg_block_bitmap, and bg_inode_table to construct the block bitmap.
The point was to keep things simple.  

The cost of doing this is that you will end up needing to initialize
the block bitmaps for every an extra 1 out of every flex_bg_size block
groups, but that's not a major cost.  It also means that BLOCK_UNINIT
and BLOCK_BG_EMPTY as defined by Andreas are the same thing.  This was
a Keep It Simple, Stupid design point; I don't think the complexity is
worth it.

If someone wants to convince me that the benefits of forcing the
kernel and e2fsck pass5 to paw through all of the block group
descriptors to construct the block bitmap outweighs the costs (and
more importantly, volunteers to write the code :-), I'm willing to be
convinced otherwise....

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