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

[Theodore Ts'o <tytso@mit.edu>]

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