linux-ext4 - Re: ext4: indirect block allocations not sequential in 3.4.67 and 3.11.7

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]

Date:	Wed, 15 Jan 2014 16:56:13 -0500
From:	Benjamin LaHaise <bcrl@...ck.org>
To:	"Darrick J. Wong" <darrick.wong@...cle.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4: indirect block allocations not sequential in 3.4.67 and 3.11.7

On Wed, Jan 15, 2014 at 03:32:05PM -0500, Benjamin LaHaise wrote:
> I tried a few tests setting goal to different things, but evidently I'm 
> not managing to convince mballoc to put the file's data close to my goal 
> block, something in that mess of complicated logic is making it ignore 
> the goal value I'm passing in.

It appears that ext4_new_meta_blocks() essentially ignores the goal block 
specified for metadata blocks.  If I hack around things and pass in the 
EXT4_MB_HINT_TRY_GOAL flag where ext4_new_meta_blocks() is called in 
ext4_alloc_blocks(), then it will at least try to allocate the block 
specified by goal.  However, if the block specified by goal is not free, 
it ends up allocating blocks many megabytes away, even if one is free 
within a few blocks of goal.

		-ben
-- 
"Thought is the essence of where you are now."
--
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