linux-ext4 - Re: fallocate creating fragmented files

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: <20130130201412.GA32724@thunk.org>
Date:	Wed, 30 Jan 2013 15:14:12 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Eric Sandeen <sandeen@...hat.com>
Cc:	Bron Gondwana <brong@...tmail.fm>, linux-ext4@...r.kernel.org,
	Rob Mueller <robm@...tmail.fm>
Subject: Re: fallocate creating fragmented files

On Wed, Jan 30, 2013 at 09:56:51AM -0600, Eric Sandeen wrote:
> Ok, TBH I'd not certain why the allocator is doing just what it's doing.
> There are quite a lot of larger-than-3-block free spaces. OTOH, it might be
> trying for some kind of locality.

Yeah, I'll bet that's what's going on.

Can you show us the the inode number for each of the test files along
with the filefrag -v output?  What I suspect is going on is that the
kernel is trying too hard to start the block allocation in the same
block group which was used for the inode number.

What we probably need to do is to have some hueristic where if we know
there are plenty of block groups with lots of large contiguous free
space, and the block group which we are preferring either because it's
the same one as the inode number, or because it's where we had
previously done the last block allocation for the file, and we the
user requests a large fallocated region, that it's better to switch
over to one of the other block groups with lots and lots of free
space.

						- 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