Btrfs против OpenZFS
Файловая система Btrfs или B-tree является новейшим конкурентом OpenZFS, возможно, самой отказоустойчивой файловой системы. Обе файловые системы имеют некоторые общие черты, такие как контрольная сумма для блоков данных, группы транзакций и механизм копирования при записи, что делает их обе нацеленными на группы пользователей. Так в чем разница и какой из них вы должны использовать?
1. Механизм копирования при записи (COW)
Обе файловые системы используют механизм копирования при записи. Это означает, что если вы пытаетесь изменить файл, ни одна из файловых систем не будет пытаться перезаписать существующие данные на диске новыми данными. Вместо этого новые данные записываются в другое место, и после завершения операции записи файловая система просто указывает на более новые блоки данных, а старые блоки со временем перерабатываются. Этот механизм позволяет обеим файловым системам иметь такие функции, как моментальные снимки и клонирование.
COW также предотвращает крайние случаи, такие как частичная запись, которые могут произойти из-за паники ядра или сбоя питания и потенциально повредить всю вашу файловую систему. При наличии COW запись либо произошла, либо не произошла, промежуточного значения нет.
2. Объединение и RAID
Обе файловые системы предназначены для устранения необходимости в диспетчере томов, рейдах и других абстракциях, которые находятся между файловой системой и дисками. Это более надежно и надежно, чем наличие аппаратного RAID-контроллера, просто потому, что он устраняет единственную точку отказа — сам RAID-контроллер.
OpenZFS предлагает стабильный, надежный и удобный механизм RAID. Вы можете зеркалировать между дисками, использовать RAIDZ1, который распределяет ваши данные по 3 или более дискам с одним блоком четности. Таким образом, он может выдержать до 1 отказа диска на Vdev. Точно так же RAIDZ2 может использовать 4 или более дисков и выдерживать отказ до 2 дисков, и аналогично у нас есть RAIDZ3.
В Btrfs тоже реализованы эти функции, разница лишь в том, что они называются RAID, а не RAIDZ и так далее. Некоторые более сложные настройки RAID-массивов, такие как RAID56, содержат ошибки и не подходят для использования на момент написания этой статьи.
3. Лицензирование
Одна из причин, по которой OpenZFS так поздно появилась в экосистеме GNU/Linux, заключается в несовместимости ее лицензии с GNU GPL. Не вдаваясь в подробности, Btrfs находится под лицензией GPL, которая позволяет пользователям брать исходный код и изменять его, но модификации также должны публиковаться под лицензией GPL и оставаться открытым исходным кодом.
С другой стороны, OpenZFS распространяется под лицензией CDDL, что является гораздо более либеральным и позволяет пользователям изменять и распространять код с большей степенью свободы.
4. Сообщества и компании, стоящие за ними
За OpenZFS стоит огромное сообщество. Сообщество FreeBSD, сообщество Illumos и многие другие проекты с открытым исходным кодом полагаются на OpenZFS и, таким образом, вносят свой вклад в файловую систему. С момента своего создания он вырос в несколько раз с точки зрения кодовой базы, пользовательской базы, функций и гибкости. Такие компании, как Delphix, iXsystems, Joyent и многие другие, полагаются на него и заставляют своих разработчиков работать над ним, потому что это основной компонент их бизнеса. Многие другие организации могут использовать OpenZFS без нашего ведома, благодаря лицензии CDDL им не нужно прямо заявлять, что они ее используют.
У Btrfs Red Hat была одним из главных управляющих своего сообщества. Тем не менее, это получило серьезный удар некоторое время назад, когда Red Hat объявила устаревшей файловую систему, это означает, что вы не увидите ее ни в одном будущем RHEL, и компания не будет предоставлять коммерческую поддержку для нее «из коробки». SUSE, однако, зашла так далеко, что сделала ее своей файловой системой по умолчанию, и их сообщество по-прежнему процветает благодаря вкладу Facebook, Intel и других 800-фунтовых горилл Силиконовой долины.
5. Надежность
ZFS разрабатывалась с самого начала, чтобы быть надежной. У людей есть zpool, созданные в начале 2000-х годов, которые все еще можно использовать и которые гарантированно не возвращают ошибочные данные молча. Да, было несколько недоразумений с исчезновением файлов для OpenZFS в Linux, но, учитывая его долгую историю, послужной список был на удивление чистым.
С другой стороны, у Btrfs были проблемы с самого начала. С глючными интерфейсами, которые приводят к потере данных и повреждению файлов. Даже сейчас это немного посмешище в обществе. Сделайте из этого что хочешь.
6. Поддерживаемые ОС
Btrfs возникла как файловая система для Linux, а ZFS была задумана внутри Sun для ОС Solaris. Однако OpenZFS уже давно перенесена на FreeBSD, Apple OS X, производные от Solaris с открытым исходным кодом. Поддержка Linux появилась немного позже, чем можно было бы предположить, но она есть, и корпорации полагаются на нее. Проект по его запуску в Microsoft Windows также довольно продвинулся, хотя он еще не совсем готов.
Заключение: заметка о монокультурах
Все эти разговоры могут убедить вас использовать OpenZFS для обеспечения безопасности ваших данных, и это неплохой способ действий. Он объективно лучше, чем Btrfs, с точки зрения возможностей, надежности, сообщества и многого другого. Однако в долгосрочной перспективе это может быть не очень хорошо для сообщества открытого исходного кода в целом.
В посте, похожем на этот, автор говорит об опасности монокультур. Я призываю вас пройти через этот пост. Суть в следующем: варианты важны. Одна из самых сильных сторон программного обеспечения с открытым исходным кодом (и программного обеспечения в целом) заключается в том, что у нас есть несколько вариантов внедрения. Есть Apache, есть Nginx, есть BSD и Linux, есть OpenSSL и есть LibreSSL.
Если в любой из этих ключевых технологий будет фатальная ошибка, мир не остановится. Но с распространением OpenZFS технология хранения превратилась в нечто вроде монокультуры. Итак, я бы очень хотел, чтобы разработчики и системные программисты, которые читают это, приняли не OpenZFS, а такие проекты, как Btrfs и HAMMER.