Что ему Гекуба? ZFS on Linux для применителя

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

В последнее время произошло несколько событий вокруг ZFS on Linux, таких, как обещание разработчиков Ubuntu штатно включить её поддержку в релиз 16.04 и его выполнение, хотя и частичное, а также появление полноценной поддержки её в дистрибутиве Antergos. По этому поводу может возникнуть вопрос: а что это даёт применителю Linux’а?

В принципе, особенности ZFS, её достоинства и недостатки многократно описывались, в том числе и на Блогосайте (самый поздний материал по теме — здесь). Однако в этом очерке будут рассмотрены в концентрированном виде те из них, которые, как мне кажется, наиболее важны для «настольного» применителя. А попутно будет сделана попытка развеять некоторые связанные с ZFS предрассудки.

Вроде бы в этой операционке и так нет недостатка в нативных файловых системах — от традиционных Ext2/3/4, через оригинальные ReiserFS и Reiser4 и портированные JFS и XFS, до модерновых log-структурированных NILFS2 и F2FS. Не обижена она и системами управления томами и многодисковыми устройствами, такими, как softRAID и LVM. Наконец, имеется даже собственная система хранения данных — BTRFS, объединяющая функции FS и VM.

Всё это изобилие свободно распространяемо, штатно поддерживается ядром Linux и применение любого её представителя не влечёт за собой никаких сложностей. Разве что не всегда все они задействуются в инсталляторах дистрибутивов, и не каждый дистрибутив включает в себя по умолчанию инструментарий для работы со всеми этими системами. Первое можно тем или иным путём обойти (или, на худой конец, подобрать дистрибутив с «нужным» инсталлятором), второе легко восполняется из репозиториев.

Напротив, использование ZFS до настоящего времени было сопряжено с рядом сложностей. Поскольку по сугубо бюрократическим причинам она штатно не поддерживается ядром Linux, применителю следовало озаботиться этой поддержкой самому. По той же причине она не включалась в инсталляторы дистрибутивов, и её задействование на стадии установки (в частности, для размещения корня файловой иерархии) требовало некоторых ухищрений. И, хотя для ZFS поддержки в загрузчике (конкретно, в GRUB) нет ни малейших препятствий, ибо необходимый для этого код был открыт ещё в незапамятные времена GRUB Legacy, патченные версии соответствующих пакетов, как говорится, на дороге не валяются.

Следует учитывать и психологический фактор: Инет буквально пестрит отзывами о ZFS как «сырой» с точки зрения быстродействия и надёжности. Правда, похоже, что авторы большинства из них в глаза ZFS не видели — но тем более безапелляционны их суждения. На фоне которых положительные отзывы об этой системе просто теряются. Ну и идеологический фактор нельзя сбрасывать со счёта: ZFS часто рассматривается как система «классово» чуждая, использовать которую правоверному линуксоиду негоже.

Начну с последнего. Так вот, код модулей поддержки ZFS и инструментария для работы с ней распространяется под CDDL (Common Development and Distribution License), которая ничуть не менее свободна, чем GPL. Ибо накладывает единственное ограничение (кроме банального заперта на присвоение авторства, разумеется) — запрет перелицензирования её в производных продуктах, причём не обязательно открытых. Именно поэтому её поддержка не может быть включена штатно в ядро Linux’а, распространяемое под GPL, о чём неоднократно говорилось, в том числе и здесь. Хотя весь связанный с ZFS код столь же открыт и свободен, как и код поддержки любой нативной файловой системы Linux.

Упрёки в адрес ZFS относительно её «сырости», особенно в сравнении с Btrfs, примерно сопоставимой по функционалу, — не более чем субъективное мнение их авторов, ибо этот параметр по определению не определим: не психрометром же её измерять, верно? Рассуждения и ненадёжности ZFS в её Linux-реализации основаны всегда на личном опыте рассуждающего. А любой применитель этой ОС с некоторым стажем накопил свой собственный негатив и позитив в отношении всех файловых систем — и, что характерно, у каждого и негатив, и позитив разный.

Например, автор этих строк никогда не сталкивался с проблемами при использовании ReiserFS — даже в те времена, когда для этого требовалось патчить ядро, и даже в условиях, близких к экстремальным (в деревне, при регулярных отключениях электричества и отсутствии бесперебойника). И в то же время он наслушался леденящих кровь историй о фатальных крахах этой файловой системы, что называется, «на ровном месте».

С другой стороны, подобный крах в моей пратике имел место быть как раз с Btrfs. Ряд не очень хороших впечатлений остался от XFS, хотя тут обошлось без всяких трагедий. И, наконец, у меня всё время была устойчивая неприязнь к Ext3, утратившей некоторые достоинства своей предшественницы, Ext2, не приобретя ещё вылизанности Ext4.

Что же касается ZFS — автор этих строк на протяжении приличного времени использовал её в FreeBSD, в OpenSolaris — в течении всего срока игр с этой ОС, и, наконец, в Linux — с 2012 года. И ни разу нигде и никогда не сталкивался не то что с какими-либо ужасами, но и просто с проблемами технического свойства. В отличие от той же Btrfs, где они возникали (у меня) достаточно часто, хотя практически использовал последнюю очень недолгое время.

Всё это сказано не с целью возвеличиванию ZFS и принижения прочих файловых систем. А исключительно к тому, что, видимо, существует определённый круг условий (и условий достаточно распространённых), где потенциальные критические недостатки ZFS, если они имеются, не проявляют себя никак. Однако то же самое можно сказать и о любой другой файловой системе. Хотя в общем случае я не скидываю со счёта такой иррациональный фактор, как банальное везение или невезение.

И,наконец, о быстродействии. Когда я слышу слова о низкой производительности ZFS, особенно не подкреплённые цифрами (а такие слова обычно ими и не подкрепляются), то у меня возникает мысль: а одна ли ZFS у меня и из авторов? Потому что чисто субъективно ZFS в практической работе на большинстве обыденных операций ничуть не медленней любой другой нативной для Linux файловой системы. Разве что Linux-реализация JFS выбивается из их ряда в худшую сторону, а Ext3, в зависимости от режима журналирования, вела себя непредсказуемым образом.

Более того, я время от времени сравнивал быстродействие почти всех файловых систем UNIX-подобных операционок на практических и повседневных задачах. И цифры подтверждали субъективные впечатления — разница в быстродействии файловых систем, конечно, есть, но на SSD она не очень заметна. Правда, при последнем моём тестировании ZFS довольно ощутимо проиграла XFS в быстродействии на ряде операций. Но тут следует учитывать, что производительность ZFS очень сильно зависит от «железа»: возможно, что для тяжёлых операций в ней просто не хватило мощи моей тогдашней машины.

В общем, если отбросить мифы и предрассудки, ZFS on Linux с точки зрения и надёжности, и быстродействия нынче предстаёт обычной файловой системой в ряду ей подобных. Но две очень важных особенностей делают её интересной для настолького применения.

Первая особенность вытекает из двойственной природа ZFS, которая не только файловая система, но и система управления томами. И потому она позволяет очень просто управлять разномастными и разнокалиберными дисками целиком и разделами на них. В пул ZFS типа stripe (аналог RAID0 — а только это и имеет смысл в настольной системе) можно объединить любое количество дисков разного размера и быстродействия. При этом суммарный объём пула не будет выравниваться на наименьшему диску, а составит просто арифметическую их сумму. Нагрузка же на пул будет распределяться так, чтобы наиболее востребованные данные оказывались на самом быстром из носителей.

Более того, при наличии небольшого и быстрого SSD и большого и «медленного» HDD можно настроить так называемый кешируемый пул, имеющий все функции аппаратных гибридных дисков из SSD и HDD «в одном стакане». Которые, как известно, стоят почему-то больше суммы из составляющих. Да при этом ещё норовят нормально работать только в одной-единственной ОС, и ОС эта, как легко догадаться, не Linux.

Вторая фича ZFS — возможность нарезать пул на любое количество файловых систем (datasets), каждая со своими опциями монтирования. Эти файловые системы по умолчанию «безразмерны», то есть не требуют предварительного расчёта места под несущие их разделы. Но при желании объём некоторых из них можно ограничить, а для других, напротив, зарезервировать. То есть сделать недоступным для «захвата» более иными файловыми системами. Причём делается это действительно также просто, как создание нового каталога в традиционной файловой системе.

Однако, повторяю, в отличие от каталогов обычной ФС, занимаемый такими dataset, может либо лимитироваться, либо резервироваться. Файловые системы с критически важными данными могут монтироваться с несколькими копиями контрольных сумм. В тех же из них, что предназначены для «парнухи», от подсчёта контрольных сумм можно отказаться вовсе. Каталоги с хорошо сжимаемыми данными могут монтироваться с компрессией. Опцию atime можно устанавливать только для тех ветвей файловой иерархии, для которых действительно необходимо знание времени последнего доступа, всем же остальным придать свойство noaime. Наконец, для отдельных файловых систем можно отключить такие свойства, как exec, setuid, devices. И, разумеется, для файловых систем, изменение которых нежелательно, можно придать свойство readonly.

В общем, оценить простоту и гибкость управления пулом ZFS и его datasets можно, только попробовав всё это в деле. И только такое опробование способно убедить, что польза от перечисленных фич (к которым в качестве своего рода «бонусов» прилагаются и многие другие) с лихвой перекрывает возможные недостатки этой системы размещения данных. Каковых, по большому счёту два.

Первый — требовательность к ресурсам. Для эффективного применения ZFS очень желательна машина с мощным 64-битным процессором под управлением Linux’а той же разрядности. Не менее важен достаточный объём оперативной памяти: указанные в системных требованиях 2 ГБ чисто символичны, на самом деле нужно не менее восьми этих самых гигабайт, а в некоторых случаях и шестнадцати. И, хотя ZFS прекрасно функционирует и на одиночном диске, в полном блеске она показывает себя при двух и более накопителях.

С аппаратными притязаниями ZFS ничего не поделаешь: эта система создавалась для риальных пацанов профессиональных применителей, а не тех, кто «понту ради» устанавливает Linux на утильную машину перед тем, как снести её на помойку.

Второй же недостаток ZFS — отсутствие штатной поддержки в ядре Linux’а и, как следствие, официальной поддержки майнтайнерами почти всех распространённых дистрибутивов. И он-то как раз преодолим и, более того, успешно преодолевается. Сначала «тихой сапой» пакеты поддержки ZFS появились во всякого рода неофициальных репозиториях ряда дистрибутивов, а затем были признаны в них официально. И, наконец, поддержка ZFS проникла в инсталляторы таких дистрибутивов, как Proxmox, с одной, серверной, стороны, и как Antegros — со стороны другой, десктопной. Я надеюсь, что это — только первые ласточки, и скоро за ними потянется всё прогрессивное майнтайнерство мира Open Source.