linux-ext4 - Re: [PATCH v2] ext4: dynamical adjust the length of zero-out chunk

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, 13 Aug 2012 17:35:47 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Zach Brown <zab@...hat.com>
Cc:	Andreas Dilger <adilger@...ger.ca>,
	Zheng Liu <wenqing.lz@...bao.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Zheng Liu <gnehzuil.liu@...il.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH v2] ext4: dynamical adjust the length of zero-out chunk

On Mon, Aug 13, 2012 at 12:49:02PM -0700, Zach Brown wrote:
> 
> Indeed.  fio to the rescue.
> 
> I remember Christoph saying something about 64k somewhat recently?  But,
> helpfully, I can't recall the details :).

So here are some quick fio numbers, using a modern 5400rpm 2.5" disk,
using 8192 samples doing random writes at different sizes:

4k     min=0.099 , max=69.980 , avg=1.95249
8k     min=0.112 , max=71.393 , avg=2.39577
16k    min=0.123 , max=79.951 , avg=3.29693
32k    min=0.190 , max=75.846 , avg=3.57158
64k    min=0.305 , max=71.386 , avg=4.43218
128k   min=0.554 , max=77.925 , avg=6.40304
256k   min=1     , max=68     , avg=10.21

If we take into account that a random write into a fallocate'd file
will need to update the extent tree, this is the time that it would
take to do a 4k random write if we are also using a more aggressive
max zero-out length (plus the extent tree block update):

        zerooout +
        4k metadata update
           (ms)
4k         3.90
8k         4.35
16k        5.25
32k        5.52
64k        6.38
128k       8.36
256k      12.16

So I can see going to 64k, but unless we're really concerned about
extent fragmentation, I don't think larger values make a whole lot of
sense, especially if we are concerned about lowering latency
variability when writing into freshly fallocate'd space.  And if the
concern is extent fragmentation, we may be better off fixing our
extent tree manipulation code so we are better at merging adjacent
extent tree blocks instead.

						- 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