Btrfs or zfs linux
I am aware that this is a btrfs-community and as such the answers here might be biased. But
I have installed ZFS on a 4 disc raid and was thinking to migrate to that, but now I have second thoughts. Especially I am missing the cp —reflink feature in ZFS.
I understand that btrfs have a major problem with Raid, — and that is a problem. But to be honest, it might be easier for me to work around than the lack of the possibility for single-file clone that btrfs, XFS etc. provides.
So please enlighten me, where is btrfs better and where is it worse or just significantly different than ZFS.
Also, instead of Raidz provided by ZFS could I just have multiple discs and use mergerFS? I am of course aware that I will not have the ability to loose a drive and still have the system go on. But copying just the one failed disc from my backup might actually not be to bad, — and also most of the time the discs arent failing. So perhaps that would actually be a fine solution to me. Or is my thinking wrong?
Edit: The self-healing is important. But just reporting «This file is corrupt, — go fetch it from your backup» might be all that I actually need. And that would work well even with no mirror/raid on btrfs, right.
Edit 2: Snapshots are important too, but if works just as well under btrfs doesn’t it? Including the ability to have a rather large amount of snapshots and also to find a tool to make auto snapshot and auto pruning?
Сравнение файловых систем 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.