Ресурс Phoronix провел очередное сравнение файловых систем XFS, BTRFS и EXT4. В данном случае в тестовой конфигурации накопителем являлся SSD и было проверено поведение как версии ядра 3.5, так и версии 3.7, находящейся в разработке.

• В тесте "Flexible IO tester (Intel IOMeter) - file server access pattern", с большим отрывом победил EXT4. На втором месте был XFS, проигравший EXT4 в 2 раза, а BTRFS в конфигурации по умолчанию проиграл в 6 раз. Можно также отметить, что в ядре 3.7 все три файловые системы улучшили свои результаты, относительно ядра 3.5.
• В тестах FS-Mark файловые системы показали производительность примерно на одинаковом уровне, тем не менее, EXT4 был немного быстрее остальных.
• В тесте dbench с приличным отрывом от остальных победил ext4, тогда как XFS и BTRFS показали примерно одинаковые результаты. Интересно также отметить что EXT4 ухудшил результат этого теста в версии ядра 3.7, в то время как остальные соперники напротив улучшили свои результаты.
• В тестах семейства IOZone файловые системы вели себя достаточно похоже, но победителем в конечном итоге стал EXT4. В ядре 3.7 все три файловых системы продемонстрировали небольшое снижение результата (регрессии).
• В тесте "threaded I/O tester - random write" с ядром 3.5 победил XFS, а с ядром 3.7 вперед вырвался EXT4. В основном это связано с тем, что в 3.7 EXT4 прибавил в скорости, а соперники наоборот испытали некоторую регрессию. Тем не менее, в целом поведение файловых систем в этом тесте отличалось не сильно.
• В тесте "compile bench - initial create", XFS и EXT4 опять устроили ожесточенную борьбу. И опять в ядре 3.5 выиграл XFS, а в 3.7 - EXT4, что связано с тем, что EXT4 в ядре 3.7 на этом тесте ускорился, а XFS напротив испытал небольшую регрессию. BTRFS в данном тесте продемонстрировал значительно более низкий результат, чем соперники, тем не менее продемонстрировав достаточно существенное улучшение поведения в ядре 3.7.

Дополнительно можно отметить публикацию результатов оценки производительности монтирования файловой системы EXT4 в режимах "nobarrier", "data=journal", "data=writeback", "nodelalloc" и "discard". В тесте Flexible IO Tester во всех режимах, кроме "data=journal" были продемонстрированы близкие результаты, использование "data=journal" замедлило прохождение теста в более чем 3 раза. Похожие результаты были получены в тестах FS-Mark и Dbench, но отставание при использовании "data=journal" сократилось до двух раз, также на 15% и 50% замедлилось выполнение теста в режиме "nodelalloc". В тесте IOZone были получены неодназначные результаты, при оценке производительности чтения данных режим "data=journal" показал самую высокую пропускную способность, но при тестировании записи отстал от остальных режимов более чем в два раза. В тесте "Threaded I/O tester" режим "data=journal" отстал в два раза, а в тесте Compile Bench почти в 5 раз.