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 06:15:23 -0400
From:	Theodore Tso <tytso@....EDU>
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 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….

-- 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