Fragmentation: Sysbench write test
The previous untar test was quite simple from a fragmentation standpoint: the extracted files are quite small and are created sequentially. But how these filesystems behave with a more complex sequential test? Let's see the sysbench sequential write test, that create 128 files, each 16 MB long (for a total of 2 GB):
Ehm... it appear that without delayed allocation (remember that the one write/one fsync() paradigm effectively disable it) BTRFS has some really BIG problem with fragmentation. This also explain the low read speed found in previous test. Give a look to the same graph without the BTRFS data point:
We can see that EXT3 is again worse than EXT4 and XFS. When used with delayed allocation, these two filesystems can score very near to the perfect one file/one fragment ratio. When we force the one write/one fsync() pattern (effectively disabling delayed allocation) the fragmentation level increase, but it remain less that 2 times the EXT3 one.
For now, we concentrated ourself on sequential write test. In this kind of tests we saw very good results from EXT4 and XFS, at a point were we can ask ourself if it is worth using an (eventually available) on-line or off-line defragmenter. How about random write test which are, by definition, much more fragmentation-prone? This test use the same 128, 16 MB long files, but rewrite on them 10000 16 KB long requests (for a grand total of over 156 MB of random written data):
The random write test show us that, in a heavy environment, all these Linux filesytems can become very fragmented. As expected, in this case the delayed allocator is of no help (it can not merge these random writes to different locations in one fragment). EXT4 seems to have a small lead over XFS and EXT3, while BTRFS is much worse. However, considering that XFS has an usable on-line defragmenter, I think that it has the edge in this test also.
UPDATE: preparing the system for another benchmark, I noticed that, in contrast to what written in Fedora 14 documentation, write barriers were non enabled on EXT3 filesystem. Please read the updated "Conclusions" page.