Нативные файловые системы Linux: очередное пузометрие

Алексей Федорчук

Мысль в очередной раз сравнить 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

А также представлены на диаграммах:

filesys-copy
Копирование, секунды
filesys-delete
Удаление, секунды

При рассмотрении диаграмм следует помнить, что речь идёт об очень маленьких абсолютных значениях, иногда составляющих доли секунды. И потому быстродействие файловых систем при операциях с данными реального проекта можно считать примерно равным, хотя ZFS здесь чуть-чуть, но выбивается в худшую сторону и при копировании файлов, и при их удалении, а показания Btrfs можно условно считать наилучшими.

Там же, где различия в скорости операций видны невооружённым глазом, то есть при копировании и удалении большого количества очень маленьких файлов и большого единичного файла, ZFS и Btrfs ведут себя сходным образом. А именно, показывают худшие результаты в первом случае и лучшие — во втором. Причём и там, и там результаты для ZFS — очень сильно худшие и столь же сильно лучшие.

Обе традиционные файловые системы занимают промежуточное положение между ZFS и Btrfs, и борьба между ними идёт с переменным успехом по фотофинишу. Исключением является удаление дерева портежей — здесь XFS показывает себя ощутимо хуже, нежели Ext4. Причём, как ни странно, но в операциях с большим файлам реванш ей тоже не светит. Хотя, казалось бы XFS именно для таких целей и разрабатывалась: Видимо, за два десятилетия, истекшие со дня её рождения, понятие «большой файл» несколько изменилось…

Всё здесь сказанное не имеет целью возвеличить или «опустить» какую-либо из упоминаемых файловых систем. А лишь служит иллюстрацией эмпирического наблюдения: на данный исторический момент формальное быстродействие (какими бы методами оно не измерялось) их — едва ли не последний критерий выбора файловой системы для настольного десктопа применителя. Подчёркиваю — не сервера любого рода (там свои расчёты и заморочки). И именно при использовании SSD — на традиционных HDD различия в быстродействии файловых систем остались теми же, что и 10 лет назад.

И, конечно, выбор файловой системы важен в некоторых специальных случаях. Например, если работа применителя заключается в копировании дерева портежей Gentoo с его последующим удалением. При выполнении столь важной и ответственной задачи следует, безусловно, избегать Btrfs и, особенно, ZFS, отдавая предпочтение традиционным файловым системам. Напротив, если цел жизни применителя — копирование максимального количества ISO-образов дистрибутивов и потибренных с Рутреккера фильмов в высоких разрешениях, ZFS и Btrfs оказываются предпочтительными.

Post Scriptum. Кстати, интересно, как поведут себя наши файловые системы и системы размещения файлов в операциях с очень-очень большими файлами, объёмом в пару-тройку десятков гигабайт? Если представится случай (в виде лишнего места на SSD и времени, которое нечем будет занять) — обязательно проверю.

Нативные файловые системы Linux: очередное пузометрие: 6 комментариев

  1. Спасибо,за очень интересный сайт,и статью!!!

  2. А что если провести сравнение линуксовых файловых систем с ZFS, у которой выключена проверка контрольных сумм блоков («zfs set checksum=off poolname/filesystem»)? Ведь в классических ФС так и есть, а значит они с такой ZFS будут сравниваться в равных условиях.

  3. Vlad, не надо меня слишком благодарить, а то я зазнаюсь и возомню о себе :)

  4. Филипп, когда я к этому относился относительно серьёзно :) — я так и делал.
    А нынче — это никакой не бенчмарк, а просто иллюстрация к тому, что на современном железе разницы в производительности FS в общем-то… не то что нету, но обычно незаметно.

  5. iZEN, у меня была такая мысль — но я от неё отказался. Потому что главным для меня было не равенство условий, а сравнение в тех условиях, в которых FS реально используются.
    Для меня, например, очень важным плюсом ZFS является именно возможность варьирования контроля сумм в разных datasets. Для большинства я оставляю умолчальную единицу, для критически важной ветви (то есть текущих проектов) ставлю трёшку, для просто важных данных (которые нужны редко, но если нужны — то нужны позарез) — двушку. Ну а всякая парнуха, к работе не относящаяся, она и сидит на checksum=off :)
    Хотя спасибо, зарубку сделал.

Добавить комментарий