Алексей Федорчук
Файловая система XFS была создана очень давно — в 1994 году, и с 2004 года штатно поддерживается ядром Linux (с её историей можно ознакомиться в онлайновой книжке Вопросы истории: UNIX, Linux, BSD и другие). На фоне новомодных файловых систем, вроде F2FS и NILFS2, и тем более таких интегрированных систем размещения данных, как ZFS и BTRFS, она, подобно рыбе латимерии, выглядит живой окаменелостью. И, казалось бы, за прошедшие двадцать лет должна была безнадёжно устареть.
Однако, как ни странно, в последние годы о старушке XFS заговорили как о рождённой заново и даже как о файловой системе будущего. В причины такого энтузиазма я вдаваться не буду — этому будет посвящён отдельный материал. Пока отмечу только, что он в значительной мере связан с решением антагонистического противоречия в этой файловой системе:
- при сборке в режиме, ориентированном на максимальное быстродействие, в ней, как ни в одной другой журналируемой файловой системе, была высока вероятность потери данных при некорректном завершении работы (например, при сбое по питанию);
- при использовании же режима
write barriers
, более или менее избавляющего от этой беды, производительность XFS на некоторых операциях деградировала просто катастрофически.
Сталкиваться с первой особенностью XFS в естественных условиях мне не приходилось, а воспроизводить ситуацию аппаратных сбоев искусственно — на рабочей машине не было ни малейшего желания. Так что я могу тут только поверить на слово гражданам, пострадавшим от сей напасти. А вот оценивать её быстродействие случалось неоднократно — и по цифрам тестов, и по впечатлениям в работе. Причём — в различные периоды жизни XFS: и когда на заре её карьеры в Linux она была действительно весьма быстрой (но, как уже сказано, по слухам опасной), и когда позднее во главу угла стали ставить задачу сохранности данных.
Результаты и тестов, и визуальных впечатлений описаны в нескольких заметках на Блогосайте, которые мне, честно говоря, искать лень, да и интерес они нынче представляют в основном исторический. Так что сформулирую своё заключение по прежним встречам с XFS в виде двух пунктов:
- неотъемлемой слабостью XFS во всей её предшествовавшей жизни была работа с большим количеством маленьких файлов; это проявлялось и в периоды ориентации на быстродействие, хотя и не столь явно, как в периоды предпочтения сохранности;
- на остальных файловых операциях в однодисковых конфигурациях XFS была на уровне всех одновозрастных ей файловых систем, родных для Linux’а, где-то выигрывая у сестёр-конкуренток, типа ReiserFS, где-то проигрывая им; но вот где она действительно блистала по всем показателям (кроме пункта первого) — это в конфигурациях многодисковых, на программных RAID’ах и системе LVM: можно сказать, что XFS и «многочленные» устройства (Multiple devices) были созданы друг для друга.
Тем интересней было сравнить быстродействие XFS и ZFS: до сих пор это удавалось мне только в различных операционных системах, Linux в первом случае и FreeBSD (и немножко OpenSolaris) — во втором. Что, разумеется, смазывало картину.
Тем не менее, за несколько лет применения ZFS сначала на FreeBSD, а затем и ZFS on Linux в отношении неё у меня сложилось то же впечатление, что и о XFS: слабость при работе с большим количеством мелких файлов (особенно их удаление) и мощь на более чем однодисковых пулах.
Поэтому, когда я принял твёрдое решение пожертвовать своим ZFS-пулом, верой и правдой служившим мне и в openSUSE, и в Ubuntu, и в Salix’е, я напоследок проделал на нём ряд измерений быстродействия некоторых файловых операций (о них — чуть ниже). А сразу после установки того же Salix’а на SSD с использованием softRAID и XFS я повторил процедуру для новой конфигурации.
Поскольку набор объектов для файловых операций, использовавшийся мной ранее на протяжении многих лет, устарел безнадёжно и совсем не отвечал реалиям сегодняшнего дня, я подобрал новые объекты, частично (из-за ограничений объёма носителей) использованные в сравнении nilfs2 и f2fs. Их перечень и объём приведены в таблице 1.
Таблица 1. Список объектов использовавшихся для файловых операциях
Объект | Ед. изм. | Объём |
Фильм BDRip.mkv | ГБ | 10,3 |
openSUSE DVD.iso | ГБ | 4,6 |
salix64-14.1.iso | МБ | 747,6 |
linux-3.14.tar.xz | МБ | 78,4 |
portage-2014003.tar.xz | МБ | 60,4 |
linux-3.14/ | МБ | 523,1 |
portage/ | МБ | 320,6 |
Измерения, как уже было сказано, проводились на
- пуле ZFS из двух SSD 120 ГБ;
- программном RAID’е с файловой системой XFS, описанном в предыдущей заметке; параметры форматирования и опции монтирования — по умолчанию, за исключением опции
noatime
, которая была добавлена руками.
Для сравнения в талице приведены два граничных случая:
- «как обычно», нынче более близкий к ситуации «бывает и хуже, но реже»: раздел с XFS на HDD 500 ГБ с интерфейсом SATA-II;
- «быстрее только в раю» — на файловой системе tmpfs, которая у меня подмонтирована (в том числе и) в каталог
/tmp
, опять же с опциями по умолчанию плюсnoatime
.
В последнем случае, из-за ограничения объёма (4 ГБ) удалось провести только часть измерений (те же, что и при сравнении nilfs2 и f2fs). Конечно, можно было бы пристегнуть раздел подкачки (при 8 ГБ оперативной памяти я необходимости его в практической жизни не чувствую от слова «вообще», и все описанные измерения проводились без него). Однако тогда потерялась бы суть идеи «абсолютного нуля» — определение скорости измерения файловых операций без обращения к блочному устройству).
Все действия выполнялись в дистрибутиве Salix 14.1 (ядро 3.10.17).
На каждом из носителей сначала выполнялись подготовительные действия. Первое — создание подкаталогов для дальнейших манипуляций:
$=> mkdir -p ~/file4test/{source,target}
И аналогично — для tmpfs:
$=> mkdir -p /tmp/file4test/{source,target}
Затем — переход куда следует:
$=> cd ~/file4test/
или
$=> cd /tmp/file4test/
Далее для единообразия вывода команды time
, с помощью которой измерялось время выполнения операций, русская локаль подменялась на локаль POSIX:
$=> export LANG=POSIX
Далее в каталог /tmp/file4test/source
копировались единичные файлы и архивы исходников ядра Linux и дерева портежей (см. табл. 1).
И наконец — собственно последовательность «измерительных» команд, сначала развёртывание тарбаллов:
$=> /usr/bin/time -p tar xJf source/linux-3.14.tar.xz source $=> /usr/bin/time -p tar xJf source/portage-20140403.tar.xz source
Затем — копирование единичных файлов и каталогов:
$=> /usr/bin/time -p cp source/Zulu_1964_1080p_BDRip.mkv target/ $=> /usr/bin/time -p cp source/openSUSE-13.1-DVD-x86_64.iso target $=> /usr/bin/time -p cp source/salix64-xfce-14.1.iso target $=> /usr/bin/time -p cp source/linux-3.14.tar.xz target $=> /usr/bin/time -p cp source/portage-20140403.tar.xz target $=> /usr/bin/time -p cp -R source/linux-3.14 target $=> /usr/bin/time -p cp -R source/portage target
И наконец — удаление всех отходов жизнедеятельности из каталога target
:
$=> /usr/bin/time -p rm -Rf target/Zulu_1964_1080p_BDRip.mkv $=> /usr/bin/time -p rm -Rf target/openSUSE-13.1-DVD-x86_64.iso $=> /usr/bin/time -p rm -Rf target/salix64-xfce-14.1.iso $=> /usr/bin/time -p rm -Rf target/linux-3.14.tar.xz $=> /usr/bin/time -p rm -Rf target/portage-20140403.tar.xz $=> /usr/bin/time -p rm -Rf target/linux-3.14 $=> /usr/bin/time -p rm -Rf target/portage
Для tmpfs дело ограничилось, разумеется, укороченной последовательностью:
$=> /usr/bin/time -p tar xJf source/linux-3.14.tar.xz --directory source $=> /usr/bin/time -p tar xJf source/portage-20140403.tar.xz --directory source $=> /usr/bin/time -p cp source/salix64-xfce-14.1.iso target $=> /usr/bin/time -p cp source/linux-3.14.tar.xz target $=> /usr/bin/time -p cp source/portage-20140403.tar.xz target $=> /usr/bin/time -p cp -R source/linux-3.14 target $=> /usr/bin/time -p cp -R source/portage target
Да, все приведённые выше команды выполнялись от лица обычного пользователя.
Вывод команды time
фиксировался во всех случаях, но итоговую таблицу были сведены только значения real
больше 1 секунды — за исключением, по понятным причинам, tmpfs, где почти все доступные операции длились меньше.
Таблица 2. Время выполнения файловых операций
ZFX vs XFS | ZFS на SSD | XFS на SSD | XFS на HDD | TMPFS |
Разворачивание linux | 8 | 6 | 8 | 6 |
Разворачивание portage | 12 | 5 | 15 | 4 |
Копирование DBDRip | 72 | 49 | 220 | — |
Копирование DVD | 30 | 20 | 95 | — |
Копирование CD | 3 | 1 | 8 | 0 |
Копирование linux | 14 | 7 | 25 | 0 |
Копирование portage | 37 | 17 | 72 | 0 |
Удаление linux | 2 | 1 | 1 | 0 |
Удаление portage | 11 | 3 | 3 | 1 |
Поскольку основными объектами сравнения выступали пул ZFS on Linux и XFS на softRAID, на диаграммах приведены результаты только для них.
Разворачивание архивов лишь частично отражает быстродействие файловых операций, процессорная составляющая тут тоже имеет место быть (что видно при значении значений для tmpfs со всеми остальным. Однако — всё-таки отражает. Во всяком случае на XFS оно происходит быстрее, чем на ZFS, причём в случае портежей — более чем в два раза:
Копирование больших файлов (и тех, что недавно считались большими) регрессивно замедляется с увеличением их объёма, однако полуторакратное превосходство XFS над ZFS сохраняется для двух «старших» случаев; к трехкратному превышению скорости для случая копирования объёма компакта, вследствие малости абсолютных величин, относиться серьёзно трудно:
Копирование каталогов с большим количеством мелких (исходники ядра Linux) и очень большим количеством очень мелких (дерево портежей) файлов показывает устойчиво двукратное превосходство XFS на ZFS:
Время удаления файлов имеет смысл рассматривать только для двух последних случаев — во всех прочих оно исчезающе мало. И тут случай для ядра Linux и дерева портежей сильно различаются. Первый каталог, не смотря на просто большое количество небольших файлов, удаляется на обеих файловых системах практически мгновенно и, условно говоря, несколько быстрее для XFS. А вот для дерева портежей, в котором, повторяю, файлов не много, а очень много, и все они очень мелкие (то есть обычно меньше логического блока файловой системы, а иногда и меньше физического блока накопителя), оказывается вполне значимым — и для ZFS почти в четыре раза большим.
Подведу итог, оказавшийся для меня несколько неожиданным. Во-первых, похоже, что разработчикам XFS действительно удалось преодолеть «врождённый порок» этой файловой системы — большую или меньшую задумчивость при работе с большим количеством мелких файлов.
Во-вторых, я не ожидал от XFS, что она обойдёт соперницу «на всех дистанциях», причём с заметным, а то и просто разгромным отрывом. Конечно, можно списать это на недоработанность реализации ZFS on Linux, потому что ранее сравнения с ZFS на FreeBSD и близко не показывали такого превосходства XFS. А также — на недостаточность «железных» ресурсов для того, чтобы ZFS проявила себя во всей красе, каковая, как утверждается, наступает при 16 ГБ памяти. Однако согласитесь, что и 8 ГБ для рядовой настольной машины обычно вполне достаточно…
А в третьих, XFS оказывается сейчас если не идеальным, то самым интересным выбором для десктопного применения. Ибо «филистёрская» ext4 банально скучна, btrfs — интересна, но недоделана (и когда будет доделана — неизвестно), ReiserFS прекратила свою активную жизнь (и изъятие её из ядра — только вопрос времени), а Reiser4 её даже и не начинала. Что же до JFS, о которой я ранее не упоминал, её реализация для Linux’а никогда не блистала выдающимися качествами.
А поскольку XFS показала себя ещё и незаурядно быстрой (ибо ZFS — тоже не медленная в ряду перечисленных файловых систем), то её выбор обосновывается не только энтузиастическими соображениями, но и вполне практическими резонами. По крайней мере, до появления в ядре поддержки файловой системы Tux3, в которой, по слухам, удалось местами превзойти «абсолютный ноль» в виде tmpfs. Хотя, видимо, не совсем честно — при отдаче tmpfs части виртуальной памяти (то есть RAM+Swap).
Что же до ZFS on Linux — казалось бы, она проиграла наши состязания с разгромным счётом. Однако она всё равно остаётся, как я уже сказал, весьма быстрой по субъективным ощущениям, если сравнивать её с ext4 или btrfs. А главное — весьма удобной в употреблении, так как совмещает в себе функции файловой системы и менеджера логических томов и мультидисковых устройств. Главный недостаток ZFS — в другом: из-за всем известного юридического кроючкотворства судьба её непредсказуема. И всегда можно опасаться того, что с выходом новой версии ядра или нового релиза какого-либо дистрибутива пакеты поддержки ZFS «не поспеют к обеду» — с такими случаями мне приходилось сталкиваться и в openSUSE, и в Ubuntu. Впрочем, это, как я уже сказал, тема для совсем отдельного материала.