Алексей Федорчук
Мысль в очередной раз сравнить ZFS по быстродействию с прочими нативными файловыми системами Linux (из которых актуальны лишь три — Ext4, XFS и Btrfs) появилась неожиданно, в ходе сочинения очерка ZFS on Linux для применителя. И к претворению её в действительность я приступил сразу, благо временно у меня пустовала половина 120-гигабайтного SSD. Она была нарезана на четыре раздела, два из которых отформатированы в Ext4 и XFS, а на третьем создан том Btrfs без разделения на субтома. Все они были смонтированы с опцией noatime
, Ext4 и Btrfs — также с опциями discard
и ssd
, соответственно.
Поскольку всё это происходило в системе MX Linux, далее потребовалось включение в ней поддержки ZFS, после чего оставшийся раздел был определён как её пул, содержащий единственную файловую систему, которой также было присвоено свойство noatime
.
Само тестирование было сведено к минимуму — копированию и удалению массивов данных в пределах каждой файловой системы. Это — единственные операции, скорость выполнения которых ещё сохраняет значение для SSD в настольных условиях. Причём массивов данных, с одной стороны, достаточно больших (на малых объёмах чувствительность метода измерения быстродействия зашкаливает в сторону ниже плинтуса), с другой — не выходящих за пределы реальности. Опыт предыдущего сравнения ZFS и XFS показал, что различие в скорости указанных операций, видимые глазом, хотя и слегка вооружённым, проявляются для трёх типов данных, более или менее реально востребованных применителем:
- больших массивов файлов очень маленького размера (то есть сравнимого с блоком файловой системы или меньшего);
- очень больших массивов разноразмерных файлов;
- просто очень больших одиночных файлов.
В качестве первого массива был избран наиболее яркий его представитель — дерево портежей Gentoo последнего разлива (на момент тестирования — portage-20160225, 408,3 МБ в распакованном виде). Второй случай был представлен, во-первых, ядром Linux текущей версии (linux-4.4.3, разворачивается в 606,3 МБ), во-вторых, материалами реального проекта Блогосайта, включающего тексты, графические файлы разного размера и даже немножко видео, суммарным объёмом 1,4 ГБ.
Как уже сказано, дело происходит в системе MX Linux, версия 15, с ядром по умолчанию — 4.2.0-0.bpo.1-amd64. Время выполнения операций определялось командой time
(подробнее здесь). Результаты приведены в таблице.
Таблица. Скорость выполнения копирования и удаления, секунды
Filesystens | ZFS | Ext4 | XFS | Btrfs | |
Копирование | alv.me | 0,92 | 0,90 | 0,79 | 0,66 |
linux | 1,70 | 1,13 | 0,87 | 1,06 | |
portage | 7,87 | 2,66 | 2,68 | 3,40 | |
DVD | 1,41 | 2,58 | 2,98 | 1,80 | |
Удаление | alv.me | 0,16 | 0,11 | 0,16 | 0,08 |
linux | 1,16 | 0,40 | 0,57 | 0,98 | |
portage | 4,75 | 1,28 | 2,08 | 2,95 | |
DVD | 0,02 | 0,47 | 0,38 | 0,34 |
А также представлены на диаграммах:


При рассмотрении диаграмм следует помнить, что речь идёт об очень маленьких абсолютных значениях, иногда составляющих доли секунды. И потому быстродействие файловых систем при операциях с данными реального проекта можно считать примерно равным, хотя ZFS здесь чуть-чуть, но выбивается в худшую сторону и при копировании файлов, и при их удалении, а показания Btrfs можно условно считать наилучшими.
Там же, где различия в скорости операций видны невооружённым глазом, то есть при копировании и удалении большого количества очень маленьких файлов и большого единичного файла, ZFS и Btrfs ведут себя сходным образом. А именно, показывают худшие результаты в первом случае и лучшие — во втором. Причём и там, и там результаты для ZFS — очень сильно худшие и столь же сильно лучшие.
Обе традиционные файловые системы занимают промежуточное положение между ZFS и Btrfs, и борьба между ними идёт с переменным успехом по фотофинишу. Исключением является удаление дерева портежей — здесь XFS показывает себя ощутимо хуже, нежели Ext4. Причём, как ни странно, но в операциях с большим файлам реванш ей тоже не светит. Хотя, казалось бы XFS именно для таких целей и разрабатывалась: Видимо, за два десятилетия, истекшие со дня её рождения, понятие «большой файл» несколько изменилось…
Всё здесь сказанное не имеет целью возвеличить или «опустить» какую-либо из упоминаемых файловых систем. А лишь служит иллюстрацией эмпирического наблюдения: на данный исторический момент формальное быстродействие (какими бы методами оно не измерялось) их — едва ли не последний критерий выбора файловой системы для настольного десктопа применителя. Подчёркиваю — не сервера любого рода (там свои расчёты и заморочки). И именно при использовании SSD — на традиционных HDD различия в быстродействии файловых систем остались теми же, что и 10 лет назад.
И, конечно, выбор файловой системы важен в некоторых специальных случаях. Например, если работа применителя заключается в копировании дерева портежей Gentoo с его последующим удалением. При выполнении столь важной и ответственной задачи следует, безусловно, избегать Btrfs и, особенно, ZFS, отдавая предпочтение традиционным файловым системам. Напротив, если цел жизни применителя — копирование максимального количества ISO-образов дистрибутивов и потибренных с Рутреккера фильмов в высоких разрешениях, ZFS и Btrfs оказываются предпочтительными.
Post Scriptum. Кстати, интересно, как поведут себя наши файловые системы и системы размещения файлов в операциях с очень-очень большими файлами, объёмом в пару-тройку десятков гигабайт? Если представится случай (в виде лишнего места на SSD и времени, которое нечем будет занять) — обязательно проверю.
Спасибо,за очень интересный сайт,и статью!!!
Обычно любой бенчмарк использует повторение операций статистически необходимое количество раз.
Вот в этой статье неплохой IOZone бенчмарк показан http://www.linux-magazine.com/Online/Features/Filesystems-Benchmarked
А что если провести сравнение линуксовых файловых систем с ZFS, у которой выключена проверка контрольных сумм блоков («zfs set checksum=off poolname/filesystem»)? Ведь в классических ФС так и есть, а значит они с такой ZFS будут сравниваться в равных условиях.
Vlad, не надо меня слишком благодарить, а то я зазнаюсь и возомню о себе :)
Филипп, когда я к этому относился относительно серьёзно :) — я так и делал.
А нынче — это никакой не бенчмарк, а просто иллюстрация к тому, что на современном железе разницы в производительности FS в общем-то… не то что нету, но обычно незаметно.
iZEN, у меня была такая мысль — но я от неё отказался. Потому что главным для меня было не равенство условий, а сравнение в тех условиях, в которых FS реально используются.
Для меня, например, очень важным плюсом ZFS является именно возможность варьирования контроля сумм в разных datasets. Для большинства я оставляю умолчальную единицу, для критически важной ветви (то есть текущих проектов) ставлю трёшку, для просто важных данных (которые нужны редко, но если нужны — то нужны позарез) — двушку. Ну а всякая парнуха, к работе не относящаяся, она и сидит на checksum=off :)
Хотя спасибо, зарубку сделал.