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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
