linux-kernel - Re: [PATCH] Clustering indirect blocks in Ext3

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: <20071116211133.GJ11339@thunk.org>
Date:	Fri, 16 Nov 2007 16:11:33 -0500
From:	Theodore Tso <tytso@....edu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Abhishek Rai <abhishekrai@...gle.com>,
	Andreas Dilger <adilger@....com>, linux-kernel@...r.kernel.org,
	Ken Chen <kenchen@...gle.com>,
	Mike Waychison <mikew@...gle.com>
Subject: Re: [PATCH] Clustering indirect blocks in Ext3

On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote:
> 
> Presmably it starts around 50% of the way into the blockgroup?

Yes.

> How do you decide its size?

It's fixed at 1/128th (0.78%) of the blockgroup.

> What happens when it fills up but we still have room for more data blocks
> in that blockgroup?

It does fall back, but it does so starting from the beginning of the
block group by using the old-style allocation routines if it can't
find any space in the metacluster region.  What I'd suggest that it do
instead is to start searching from the end of metacluster region, and
then wrap around to the beginning of the block group, and then if it
can't find any blocks when it reaches the beginning of the metacluster
region, then go to the next block group that would be used by
ext3_new_blocks(), and start searching in the metacluster region ---
that way a smart e2fsck that is doing clustering could just arrange to
pre-read the metacluster region for each block group, and if it finds
an indirect block that is another block group's metacluster region, it
could try reading in those blocks too.

In order to do this, I'd suggest considering to fold ext3_new_blocks
and ext3_new_indirect_blocks() into the same function, with just a
passed-in flag to indicate whether for each block group the
metacluster region or the non-metacluster region should be searched
first.  This would also make elimiate some duplicated code.

> Can this reserved area cause disk space wastage (all data blocks used,
> metacluster area not yet full).

No, not as far as I can see.

> Less speedup, for more-and-smaller files, it appears.
> 
> An important question is: how does it stand up over time?  Simply laying
> files out a single time on a fresh fs is the easy case.  But what happens
> if that disk has been in continuous create/delete/truncate/append usage for
> six months?

Another question is how does it stand up if the average size of files
is different from what you anticipate?  If the files are bigger than
you expect, or smaller than you expect, then the ratio of indirect
blocks to data blocks will be different, at which point allocations
won't be perfectly split up between metacluster region.

For this reason, the exact size of the metacluster region should
probably be a superblock tunable --- and once we have the superblock
tunable, I'd use the non-zero metacluster size to determine whether or
not to enable this feature, and not to use a mount option.  Mount
options really should be avoided whenever possible, in favor of
settings in the superblock.

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/