linux-ext4 - Re: [RFC] BIG_BG vs extended 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 2 Jul 2007 11:49:39 -0400
From:	Theodore Tso <tytso@....edu>
To:	"Jose R. Santos" <jrs@...ibm.com>
Cc:	Andreas Dilger <adilger@...sterfs.com>,
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4

On Sun, Jul 01, 2007 at 09:48:33AM -0500, Jose R. Santos wrote:
> Is your concern due to being unable to find contiguous block in the
> case that a bad disk area is in one of the bitmap blocks?  One thing we
> can do is try to search for another set of contiguous blocks and if we
> fail to find one, we can flag the block group and move to an indirect
> block approach to allocating the bitmaps.  At this point, we do lose
> some of the performance benefits of BIG_BG, but we would still be able
> to use the block group.

Yes, my concern is what we might need to do if for some reason e2fsck
needs to reallocate the bitmap blocks.  I don't think an indirect
block scheme is the right approach, though; we're adding a lot of
complexity for a case that probably wouldn't be used but very, very
rarely.

My proposal (as we discsused) in the call, is to implement BIG_BG as
meaning the following:

	1) Implementations must understand and use the s_desc_size
	superblock field to determine whether block group descriptors
	are the old 32 bytes or the newer 64 bytes format.  
	
	2) Implementations must support the newer ext4_group_desc
	format in particular to support bg_free_blocks_count_hi and
	bg_free_inodes_count_hi

	3) Implementations will relax constraints on where the
	superblock, bitmaps, and inode tables for a particular block
	group will be stored.

So with that, we can experiment with what size block groups really
make sense, versus using the extended metablockgroup idea, or possibly
doing both.

						- 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