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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20070701123054.GC28917@thunk.org>
Date:	Sun, 1 Jul 2007 08:30:54 -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 Sat, Jun 30, 2007 at 11:39:08PM -0500, Jose R. Santos wrote:
> On Sat, 30 Jun 2007 01:51:25 -0400
> Andreas Dilger <adilger@...sterfs.com> wrote:
> > I don't think there is actually any fundamental difference between these
> > proposals.  The reality is that we cannot change the semantics of the
> > META_BG flag at this point, since both e2fsprogs and ext3/ext4 in the
> > kernel understand META_BG to mean only "group descriptor backups are
> > in groups {0, 1, last} of the metagroup" and nothing else.
> 
> Agree.  I call it extended META_BG for lack of a better name, but a new
> feature flag will be required.

It was the intention that META_BG include allowing the bitmap and
inode tables to range anywhere outside of the block group, but that
never got coded.  It would be confusing though if we relaxed it
withotu adding a feature bit, and I agree that we might as well use
overload the BIG_BG group to indicate this feature.

The fact that BIG_BG requires contiguous blocks for the bitmaps when
they exceed blocksize*8 blocks still concerns me a minor amount, and
given the hopeful inclusion of kernel patches that allow blocksize >
pagesize.  Furthermore, I still wonder whether we will want to make
blockgroups that much bigger (since reducing the allocation groups is
not necessarily a smart thing; we will need to do some benchmarks with
filesystem aging to see how this affects antifragmentation efforts),
but the complexity engenered by adding BIG_BG isn't that bad (again,
my only concern is with the contiguous bitmap blocks requirements).

						- 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