Прежде чем погружаться в вопросы, связанные с ZFS, читатель, вероятно, хотел бы убедиться в том, что это стоит делать. То есть — ознакомиться с возможностями, которые она ему предоставляет. Возможно, с этого следовало бы начать весь цикл рассказов — но так уж исторически сложилось, что до особенностей ZFS я добрался только сейчас.

Для начала — немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на её объём и объёмы её составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика, для её заполнения данными и их хранения потребовалось бы вскипятить океан.

Так, объём пула хранения данных (zpool — максимальная единица в системе ZFS) может достигать величины 3×1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы измерения). Каждый пул может включать в себя до
264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.

Дальше всё продолжается в том же духе. Пул может быть разделён на 264 наборов данных (dataset — в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт.

Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения. И достигнуть их не по силам не только пользователю индивидуального десктопа, к коему я , но и суперадмину крутейшего data-центра. А привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнуться ограничениями на размер файловой системы или отдельного файла. То есть с тем, что мы проходили при использовании FAT любого рода, или, скахем, ext2fs.

Так что перейду к особенностям ZFS, наиболее интересным десктопному пользователю, и к кому в основном и обращаю свои сочинения. По моему мнению, разумеется — ибо сам таковым являюсь.

Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчётом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно.

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

Пул накопителей становится доступным для работы сразу после его создания, без рестарта машины. Разве что в Linux’е, по причинам, рассмотренным ранее http://suseana.ml/?p=671, потребуется озаботиться установкой необходимых пакетов и подгрузкой модулей поддержки для ядра системы. В процессе работы дополнительные диски или разделы, в том числе и устройства кэширования могут как присоединяться к пулу, так и изыматься из его состава. Ни то, ни другое действие также не требует останова системы (если сами устройства допускают «горячее» подключение) или её перезапуска. Правда, и в отношении присоединения, и изъятия напопителей существует ряд ограничений.

Далее, пул накопителей может быть разделён на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растёт по мере заполнения данными (при наличии достаточного свободного пространства, разумеется). Это избавляет пользователя от необходимости расчёта места, потребного под логи системы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объёма отдельных файловых систем — например, домашних каталогов отдельных излишне жадных пользователей.

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

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

Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:

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

В общем, даже если не говорить об быстродействии XFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять её достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у неё недостатки?

Разумеется, есть. Хотя большая часть того, что обычно отмечается как недостатки, являются скорее особенностями (например, ограничения при добавлении или удалении накопителей в пуле). И к тому же, как правило, не существенны для пользователя десктопа. Спорным также представляется вопрос с поддержкой TRIM для SSD-накопителей. Точнее, полным её отсутствием в ZFS. Что, с одной стороны, вроде бы однозначный минус. А с другой — так и уж важна команда TRIM при используемом в ZFS механизме копирования при записи (Copy-On-Write, COW)? В любом случае, я пока никаких бед от этого не заметил.

По большому счёту для пользователя Linux’а у ZFS обнаруживается два кардинальных недостатка:

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

Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа сотоварищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.


Назад | Рассказы о ZFS | Вперёд