Сравнение файловых систем ZFS, BTRFS и XFS : Linux

Религиозные споры о том, какая файловая система лучше, начались еще во времена главенствования UNIX и DOS. Предлагаю не быть фанатиками в оценке возможностей той или иной системы, а выбирать их по своим условиям в каждом конкретном случае. Я попробую перечислить основные характеристики файловых систем на данный момент, прошу присоединяться к дискуссии.

В свете раздела, давайте договоримся, что речь идет о Linux. Да, я знаю, какое место занимает там ZFS (в виде официального порта OpenZFS, называемом ZFS on Linux). Увы, лицензионная политика Oracle не позволила включить эту замечательную файловую систему в ядро и, соответственно, в промышленной эксплуатации могут быть серьезные проблемы с техподдержкой, тем не менее, в некоторых предприятиях ZFS работает на Linux уже долгое время.

В свете заданной темы не будем рассматривать и все множество файловых систем, особенно ext*, которые, на мой взгляд, отжили свое, хотя и очень честно трудились, заслуживая самые высокие оценки. Хотите поспорить - прошу в отдельную тему.

В настоящий момент основной законодатель мод, Red Hat, настойчиво продвигает XFS и предлагает коммерческую поддержку для этой файловой системы, BTRFS почему-то резко сократила свое присутствие в отчетах этой компании, в свое время даже какие-то непонятные слухи о скором закрытии проекта были, но, тем не менее, силами SLES, как минимум (если говорить о крупных игроках), эта система продолжает активно развиваться. Как говорил выше, ZFS со своей лицензией CDDL, держится особняком и предполагает некоторые трудности с обновлением ядра, в который интегрирует свои модули.

Если говорить о поддержке со стороны разных OS, то на Linux все системы присутствуют в стабильном виде, на FreeBSD работает ZFS и экспериментально XFS, на Mac OS только ZFS в экспериментальном варианте, убогая Windows вообще не поддерживает ни одну, хотя начальные попытки какие-то были. Упомяну, что форки похороненной OpenSolaris, такие, как Illumos, SmartOS и OmniOS, поддерживают Open ZFS, как основную.

Ключевой особенностью ZFS и BTRFS является CoW, copy-on-write, копирование при записи. Опция, очень сильно снижающая вероятность повреждения файлов при случайном выключении питания или выпадании операционной системы в корку. Суть ее в том, что при перезаписи данных в файле, данные записываются не поверх старых, а на пустое место, а уже после подтверждения успешного окончания записи в FS производится освобождение старых данных. Если во время записи дернуть рубильник, останутся старые данные, а не наполовину переписанные, как, увы, происходит в случае с XFS, основным преимуществом которой является скорость параллельных операций и, особенно, записи. При работе с большими файлами, например, образами виртуальных машин или базами данных, конкурентов у XFS нет. Увы, для работающих виртуальных машин и баз данных CoW, скорее всего, придется отключить, хотя, например, на SPARC-Solaris ZFS это не требует.

Дополню, что и ZFS, и BTRFS поддерживают контрольную сумму блоков данных, а так же возможность объединять устройства в массивы, что на выходе дает просто бронебойную (в пределах разумного, конечно) целостность данных. XFS, увы, только метаданные (описание собственной структуры) проверяет контрольной суммой, хотя от одного из разработчиков была информация, что XFS будет поддерживать и контрольную сумму данных. На текущий момент выключение питания может привести к появлению на XFS файла из нулей, поскольку метаданные записываются отдельно от данных, которые могут задержаться в буферах, средств защиты от bit-rot и других незаметных повреждений носителя в XFS нет.

ZFS - 128-битная файловая система, в то время как BTRFS и XFS - 64-битные. На самом деле тут больше разница в потребяемых ресурсах, поскольку даже 64-битные системы подразумевают возможность хранения 2^64 файлов и максимальный размер файлов в 8 экзабайт. Для ZFS эти лимиты настолько огромны, что я затрудняюсь их назвать в определениях максимальных чисел. Однако, несмотря на эти недостижимые лимиты размеров и количества, все файловые системы имеют ограничение имени файла в 255 символов.

Еще одной архитектурной особенностью, отделяющей "родные" Linux-системы от ZFS, является индексация файлов с помощью B-tree, что разительно ускоряет скорость поиска и перебор файлов на диске. Причем, кеширование ли или организация этого индекса у BTRFS настолько хорошо реализованы, что перебор файлов на этой FS идет значительно быстрее остальных.

Если перейти дальше к функционалу, то тут на арене исключительно ZFS и BTRFS. У XFS нет, ни сжатия, ни возможности объединять устройства. В противостоянии же первых двух можно отметить, что ZFS стабильнее более функционально работает с объединением устройств, причем, хоть и не без замечаний по поводу разделения команд на zpool и zfs, синтаксис у ZFS гораздо более понятный и логичный, легче запоминается. У BTRFS гораздо лучше все со сжатием, особенно с появлением ZSTD в арсенале. Но и у ZFS есть сжатие (хоть и меньше вариантов алгоритмов, чем на родных платформах). Зато у ZFS есть дедубликация (хранение одной копии одинаковых файлов) и дублирование блоков, когда можно указать, чтобы каждый блок файла записывался не один раз, а заданное количество раз. В общем, функционал у ZFS куда богаче, чем у BTRFS и уж, тем более, XFS. Но, BTRFS растет и развивается, впрочем, это может сказаться и на надежности решения. С другой стороны, ZFS, получается, хоть и обладает старой, проверенной кодовой базой, тоже не стоит на месте и в апреле 2018 был выпущен релиз с возможными потерями данных, который, правда, практически сразу убрали. У BTRFS как минимум, пару лет назад уже было такое. От ошибок не застрахован никто.

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

Поддержку TRIM обеспечивают все указанные файловые системы, тут придраться не к чему.

Изменение размеров у всех систем есть в большую сторону, но только у BTRFS - в меньшую. У ZFS нет дефрагментации. У XFS и BTRFS есть онлайновая. В силу архитектуры и сферы применения, я думаю, она особо и не нужна.

Восстановление удаленных файлов, можно сказать, не работает нигде.

По поводу использования ресурсов. Достаточно много копий сломано на почве того, что ZFS слишком прожорлива. Это одновременно и так и нет. Во-первых, на Linux эта файловая система не может пользоваться общим файловым кешем. Для ZFS это отдельная область памяти, которую надо определить, никакой динамики, как в случае с родными файловыми системами. Не определите - будет неожиданно тупить. За все надо платить, если включите дедубликацию, то памяти действительно придется адское количество вложить. Из приятных возможностей - можно использовать медленные винты и часть кеша положить не в память, а на SSD.

Выводы, мое личное мнение:
XFS использовать надо там, где целостность данных неважна, где они вторичны или могут быть проверены/восстановлены при том, что требуется быстрая работа с большими файлами. Под базы данных и торренты.

BTRFS - среднее между ZFS и XFS, подходит для неторопливых десктопов с ценными данными, например, разработчику. Можно так же использовать для бекапов на тех же десктопах. Золотая середина и рекомендуемая мной система, пожалуй, если речь идет о хранении данных. В силу отсутствия отдельного сервера, я свои данные храню на 2хBTRFS

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

Чтобы немного актуализировать тему.
Сейчас все архивы держу на XFS. BTRFS один раз круто развалилась у жены на ноуте после нештатного выключения питания. Развалилась совсем и вообще, т.е. ни единого файла.
В свете еще недавно всплывшей особенности, что BTRFS сильно убивает SSD, я перестал ее вообще использовать. Да, все как-то ее стали закапывать, никакого взрывного развития, которое требуется и подразумевается.
Недавно сравнивал ZFS, XFS и EXT4. Признаюсь честно, EXT4 на диске в один поток рвет всех. Совсем чуть-чуть отстает XFS, которую я все равно не стал менять в силу преимуществ многопоточного доступа и отсутствия этих раздражающих lost_found в каждой точке монтирования. ZFS крута по функционалу, но отстает при обычных однопоточных операциях, а при удалении файлов все вообще плачевно. В общем, для десктопа рекомендую EXT4, для сервера XFS, для файлопомойки с ценным все же ZFS, с не очень ценным - XFS.

недавно стал замечать, что некоторые копирования становятся просто стремительными (см. гифку)
Выяснилось, что в XFS теперь есть reflink

В свете того, что в Fedora заикнулась о возможном использовании BTRFS по умолчанию, я снова взялся за сравнительные тесты. Итак, у меня сейчас под виртуалки - ZFS. Работает изумительно, и единственное, что я могу ей предъявить - прилепленность сбоку в виде dkms и выделение памяти под кеш отдельно.
Стал тестировать. Именно под виртуалки.
Вот ZFS с моими штатными настройками:




Точно такой же диск с BTRFS (zstd):




И он же, но с lzo:




Виртуалки на BTRFS и обычном диске работают сильно медленнее. Вплоть до неприятного. Например, Win7 выключается полминуты, хотя на ZFS этот процесс практически моментальный.

При копировании образа обратил внимание, что с ZFS читается меньше, чем пишется на BTRFS.
Если включить zstd:15, то на колени падает проц, хотя скорость все равно не больше, чем на ZFS.
Если играть с dd, то при записи из /dev/zero сжатие lzo и zstd дало около 650М на 20Гб файлик, а lz4 на ZFS дало около 1М. Разительное отличие.
Что из неприятного еще - если запустить винду на BTRFS и ничего не делать, то кеш вымывается (хотя я больше ничего и не делал) и запуск того же FireFox производится со страшным скрипом.
Запуск винды, особенно повторный, тормознее сильно на BTRFS, где-то полминуты анимации флажка, хотя на ZFS второй запуск практически моментальный.
Пытался убивать обе файловые системы выключением питания во время записи - безуспешно. Просто после заявлений о том, что ZFS просто все держит в памяти, было немного удивительным обнаружить, что файл из dd больше на ZFS, чем на BTRFS.
В общем, в свете тормозов пока остался на ZFS...