linux-ext4 - Re: bigalloc and max file size

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:	Mon, 31 Oct 2011 11:53:42 -0700
From:	Sunil Mushran <sunil.mushran@...cle.com>
To:	Tao Ma <tm@....ma>
CC:	Theodore Tso <tytso@....EDU>,
	Andreas Dilger <adilger@...mcloud.com>,
	linux-ext4 development <linux-ext4@...r.kernel.org>,
	Alex Zhuravlev <bzzz@...mcloud.com>,
	"hao.bigrat@...il.com" <hao.bigrat@...il.com>
Subject: Re: bigalloc and max file size

On 10/31/2011 03:27 AM, Tao Ma wrote:
> On 10/31/2011 06:15 PM, Theodore Tso wrote:
>> On Oct 27, 2011, at 11:31 PM, Tao Ma wrote:
>>
>>> Forget to say, if we increase the extent length to be cluster, there are
>>> also a good side effect. ;) Current bigalloc has a severe performance
>>> regression in the following test case:
>>> mount -t ext4 /dev/sdb1 /mnt/ext4
>>> cp linux-3.0.tar.gz /mnt/ext4
>>> cd /mnt/ext4
>>> tar zxvf linux-3.0.tar.gz
>>> umount /mnt/ext4
>> I've been traveling, so I haven't had a chance to test this, but it makes no sense that changing the encoding fro the extent length would change the performance of the forced writeback caused by amount.   There may be a performance bug that we should fix, or may have been fixed by accident with the extent encoding change.
>>
>> Have you investigated why this got better when you changed the meaning of the extent length field?   It makes no sense that such a format change would have such an impact….
> OK, so let me explain why the big cluster length works.
>
> In the new bigalloc case if chunk size=64k, and with the linux-3.0
> source, every file will be allocated a chunk, but they aren't contiguous
> if we only write the 1st 4k bytes. In this case, writeback and the block
> layer below can't merge all the requests sent by ext4. And in our test
> case, the total io will be around 20000. While with the cluster size, we
> have to zero the whole cluster. From the upper point of view. we have to
> write more bytes. But from the block layer, the write is contiguous and
> it can merge them to be a big one. In our test, it will only do around
> 2000 ios. So it helps the test case.

Am I missing something but you cannot zero the entire cluster because
block_write_full_page() drops pages past i_size.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=5693486bad2bc2ac585a2c24f7e2f3964b478df9
--
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