Глава 3. Пулы

Содержание

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

Блоки ZFS

Традиционные файловые системы, такие как UFS и extfs помещают данные на диск в блоки фиксированного размера. Файловая система имеет специальные блоки, называемые индексными дескрипторами (inode), которые служат указателем того какой подлежащий блок принадлежит какому файлу. Даже не Unix файловые системы, подобные NTFS и FAT применяют аналогичные структуры. Это является стандартом во всей индустрии.

ZFS не выполняет предварительную настройку специальных индексных блоков. Она использует только блоки хранения, также называемые областями чередования (полосами, stripe). Каждый блок содержит указательную информацию для связи этого блока с другим блоком в дереве диска {Прим. пер.: см. схему на Рисунке 10.5. Структура ZFS в нашем переводе Главы 10. ZFS: Зеттабайт файловая система 2й редакции книги Маршала Кирка МакКузика, Джорджа В. Невил-Нейла и Роберта Н.М. Ватсона "Архитектура и реализация операционной системы FreeBSD" (ISBN-13: 978-0-321-96897-5).} ZFS вычисляет хэши всей информации в блоке и сохраняет эту информацию в самом блоке и в родительском блоке. {Прим. пер.: подробнее о структуре блочных указателей см. схему на Рисунке 10.4. Описание указателя на блок в том же нашем переводе.} Каждый блок является завершенной единицей сам по себе. Файл может быть частично утрачен, но, то что осталось, будет согласовано.

Отсутствие специальных индексных блоков звучит здорово, но, безусловно, ZFS должен где-нибудь начинаться! Каждое дерево данных нуждается в корне. ZFS использует специальный блок называемый uberblock для хранения указателя на корень файловой системы. ZFS никогда не изменяет данные на диске - даже когда блок изменяется, записывается новая копия блока целиком вместе с измененными данными. (Мы обсудим эту функциональность копирования-при-записи более глубоко в Главе 6.) Пул данных резервирует 128 блоков под uberblock, используемые последовательно по мере изменений в их пуле. Когда используется последний uberblock, ZFS возвращается назад к началу.

uberblock не являются единственными критичными блоками. ZFS копирует блоки,содержащие жизненно важную информацию, такую как метаданные файловой системы и данные пула в несколько повторный блоков ditto block. Если главный блок разрушен, ZFS проверяет повторный блок на наличие резервной копии. Повторные блоки сохраняются на максимально возможном удалении друг от друга, либо на отдельных дисках, либо в разных разделах одного диска (ZFS не имеет специальной способности видеть схему расположения дисков, но она делает смелые предположения).

ZFS фиксирует свои изменения на носителе хранилища в группах транзакций, или txg (transaction group). Группы транзакций содержат несколько пакетных изменений и имеют инкрементальный 64- битный номер. Каждая группа транзакций использует последующий uberblock в очереди. ZFS определяет самый последний uberblock из группы со 128 членами находя uberblock с наибольшим номером группы транзакций.

ZFS на самом деле использует некоторые блоки для индексацииЮ однако эти znode и dnode могут использовать любой блок хранения в пуле. Они не похожи на индексные записи UFS2 и extfs, определяемые при создании файловой системы.

Чередование, RAID и пулы

Вы наверняка слышали словосочетание область чередования (полоса, stripe) в связи с хранением, вероятно много раз. Пул ZFS "чередует" данные по виртуальным устройствам. Традиционный RAID "чередует" данные по физическим устройствам. Что такое область чередования (полоса), и, как она участвует в пуле?

Область чередования (полоса) является фрагментом данных, который записывается на отдельное устройство. Большинство традиционных RAID использует размер блока 128 кБ. Когда вы пишете файл на традиционное устройство RAID, программное обеспечение RAID записывает на каждый диск фрагмент в 128 кБ, причем обычно одновременно. Аналогично, чтение с традиционного массива RAID происходит инкрементально по размеру области чередования. Хотя вы можете настроить размер области чередования для соответствия нагрузке сервера, емкость оборудования и пределы программного обеспечения в значительной степени ограничивают размер области чередования.

Чередование не предоставляют никакой избыточности. Традиционные RAID получают избыточность путем избыточного кодирования и / или зеркалирования. Пулы ZFS получает любое резервирование от лежащих в их основе VDEV.

ZFS размещает чередование на движимые реактивной тягой роликовых коньки. Набор данных ZFS использует размер блока по умолчанию 128 кБ, но ZFS достаточно умен, чтобы динамически изменять этот размер области чередования (полосы), чтобы соответствовать оборудованию и рабочей нагрузке. Если размер полосы 32 кБ имеет смысл для определенного пакета данных, а 64 кБ подходит для другой части данных, то ZFS применит соответствующий размер для каждого из них. Разработчики ZFS завершили поддержку полосы размером до 1 Мб. Эта функция уже доступна в FreeBSD-CURRENT, и, как ожидается, будет включена в FreeBSD 10.2 и более поздние версии.

Пул ZFS имеет гораздо большие возможности, чем традиционные RAID. Традиционный RAID имеет фиксированную и негибкую структуру данных (хотя некоторые производители аппаратного обеспечения имеют свои собственные системы RAID с большей гибкостью). Программное обеспечение RAID записывает на каждый диску в предопределенном порядке. ZFS обладает большей гибкостью. Если у вас есть традиционный RAID массив с пятью дисками, этот массив всегда будет иметь пять дисков. Вы не можете изменить массив путем добавления дисков. Хотя вы могли бы заменять диски на диски большего размера, выполнение такой замены не будет изменять размер массива. Создание RAID устройства цементирует основные характеристики массива.

Пулы ZFS не только допускают изменения, но они также предназначены для легкой адаптации добавлений. Если у вас есть пул ZFS с пятью VDEV, а вы хотите добавить шестое, это нормально. ZFS принимает эти VDEV и начинает чередовать данных и на это устройство, даже не мигнув. Вы не можете добавлять хранилища в RAID-Z VDEV, добавление возможно только в пулы VDEV. Число поставщиков в VDEV RAID-Z фиксируется в момент создания.

В ZFS, однако, такое виртуальное устройство может быть любого поддерживаемого ZFS типа VDEV. Возьмите два VDEV, которые являются зеркалированной парой. Поместите их в отдельный zpool. ZFS будет создавать в них чередование данных. В традиционном RAID, чередование поверх зеркала можно было бы назвать RAID-10. В большинстве случаев использование RAID-10 является RAID с самой высокой производительностью, которую вы можете получить. Тогда как традиционные RAID-10 имеют фиксированный размер, вы, однако, можете добавлять дополнительные VDEV в пул. Расширение вашего RAID-10 означает резервное копирование данных, добавления дисков в массив RAID с последующим восстановлением данных. Расширение вашего zpool означает добавление большего числа VDEV в пул RAID-10, к тому же, допускает толщину до двух дисков, в то время как ZFS допускает глубину до 2⁶⁴.

Отметим, однако, что пулы не предоставляют никакой избыточности. Все резервирование ZFS поступает от лежащих в основе VDEV.

Просмотр пулов

Для просмотра всех пулов в вашей системе выполните zpool list.

# zpool list
NAME   SIZE  ALLOC  FREE  EXPANDSZ  FRAG  CAP  DEDUP  HEALTH  ALTROOT
db    2.72T  1.16G  2.72T       -     0%   0%  1.00x  ONLINE  -
zroot  920G  17.3G  903G        -     2%   1%  1.00x  ONLINE  -

Первая колонка дает имя пула. Данная система имеет два пула db и zroot.

Следующие три колонки сообщают информацию о размере и использовании каждого пула. Вы получите размер, объем используемого пространства и количество свободного пространства.

Колонка EXPANDSZ показывается если лежащий в основе производитель хранения имеет какое-то свободное пространство. Вы можете иметь возможность расширить объем пространства в этом пуле, как обсуждается в Главе 5. Это пространство включает блоки, которые пойдут под информацию контрольных сумм, следовательно расширение пула не даст вам так много пространства для использования.

Под FRAG вы увидите количество фрагментаций в данном пуле. Фрагментация вызывает деградацию производительности системы.

Клонка CAP показывает какой процент доступного пространства используется.

Элемент DEDUP отображает количество случившихся в файловой системе дедупликаций. Дедупликации охватывает Глава 6.

Колонка HEALTH пула отражает состояние лежащих в основе VDEV. Если поставщик хранения отказал, первым намеком вам будет любое отличное от ONLINE состояние. Глава 5 обсуждает работоспособность пула.

Наконец, ALTROOT показывает где смонтирован данный пул или его "альтернативный корень". Глава 4 охватывает альтернативные корни. {Прим. пер.: так в оригинале, на самом деле обсуждение свойства altroot идет только в разделе Переименование импортированных пулов в Главе 5.}

Если вы хотите узнать информацию об определенном пуле или пулах, приведите список пулов после zpool list. prod и test

# zpool list prod test

Если вы хотите более подробную информацию по вашим пулам, включающую использование лежащих в основе дисков, добаьте параметр -v. Вы должны определить параметр до имени пула.

# zpool list - v zroot

Флаг -p печатает числа в байтах вместо более дружественного пользователю формата, а -H прекращает выводить заголовки колонок. Эти параметры полезны для автоматизации и сценариев управления.

Для более подробного просмотра пулов, включающего разметку лежащих в основе VDEV воспользуйтесь zpool status. Мы увидим много примеров zpool status когда мы создаем пулы.

Чтобы кратко проверить ваш пул, выполните zpool status -x.

# zpool status - x
all pools are healthy

Порой это все, что вам нужно.

Множество VDEV

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

Глава 2 рассказывает о производительности различных типов VDEV. Эта производительность проникает вверх на уровень пула. Если вы читаете большой файл с множества VDEV, чтение файла завершится когда последний (обычно самый медленный) диск закончит вызов своей части общих данных. Если ваш пул, однако, включает в себя множество VDEV, такой самый медленный диск содержит только фрагмент файла, несколько снижая время, необходимое для доступа к нему. Помните, что самая медленная часть данных, считываемая с поставщика хранения выставляет головку в правильное место диска для вызова этих данных оттуда, следовательно это будет не простое деление времени на число VDEV - однако дополнительные VDEV в пуле улучшают производительность.

Лучшая практика требует использовать только идентичные VDEV хранения в пуле. Если у вас в пуле находится куча зеркалированных VDEV, не добавляйте в него устройство RAID-Z3. Смешение VDEV хранения страшно запутывает производительность пула и делает работу ZFS более тяжелой, поскольку она оптимально распространяет данные между устройствами. Вы можете сделать это, но вы не должны этого делать! (ZFS следует традиции Unix, не запрещающей делать глупые вещи, поскольку это также могло бывам помешать делать умные вещи.)

Удаление VDEV

В настоящее время вы не можете удалить VDEV из пула. Каждое VDEV имеет записанные на нем данные. Вы можете удалять диски из VDEV определенного типа, Однако VDEV как целое имеет записанные на нем критические данные пула. Например, вы можете удалить диск из зеркалированного VDEV, однако вы не можете удалить все VDEV из пула. Обычно вы удаляете диск из VDEV только когда он отказывает. Принудительное удаление VDEV из пула - скажем, путем выдергивания поставщика хранения - разрушит пул. Возможность удаления VDEV из массива с чередованием или зеркала, как ожидается, появится в конце 2015, но она пока еще не возможна. Поддержка для удаления RAID-Z устройств нанесена в дорожную карту, но работа над ней еще не начата.

Это означает, что вы не можете сжимать пул. Если вы хотите сделать пул меньше, вы должны переместить данные в новый пул меньшего размера, а затем утилизировать диски из первоначального пула.

Выравнивание пулов и размер сектора диска

ZFS ожидает наличие глубоких знаний о носителе информации, включающих размер сектора лежащего в основе поставщика. Если ваши пулы не применяют правильный размер сектора, или если секторы ZFS не совпадают по размеру с физическими секторами на вашем диске, производительность вашего хранилища упадет наполовину или более. Это ортогональные проблемы, но исключение при планировании хотя бы одной приведет к краху вашей системы. {Прим. пер.: см. перевод статьи Ильи Крутова (IBM) Обзор технологии Расширенного формата жестких дисков с обсуждением данных проблем на уровне дисковых форматов.}

Мы обсудим выравнивание раздела и размер сектора ZFS раздельно.

Выравнивание раздела

Диск сообщает свой размер сектора, следовательно это не проблема - за исключением тех случаев, когда она есть. Многие диски сообщают, что они имеют сектора с 512 байтами, однако на самом деле они имеют сектора 4096 байт (4К). FreeBSD Mastery: Storage Essentials обсуждает это достаточно глубоко, поэтому мы не будем проходить через эти болезненные подробности здесь. {Прим. пер.: см. перевод статьи Ильи Крутова (IBM) Обзор технологии Расширенного формата жестких дисков с обсуждением данных проблем на уровне дисковых форматов.}

Старые схемы управления разделами, подобные почтенной (MBR, Master Boot Record), содержащей все возможные виды непостижимой математики для того,чтобы убедиться, что разделы диска соответствуют физическим характеристикам своего диска. Современные схемы разделов, подобные GPT (GUID Partition Tables) знают, что физические диски разговаривают с раздвоенным языком и что эти старые ограничения на основе MBR полностью фиктивные и требуют только того, чтобы разделы заполняли все секторы.

Однако когда диск лжет о своем размере сектора, gpart(8) позволяет создавать разделы, которые могут могут начинаться или заканчиваться в посредине физического сектора. Каждые чтение и запись на диске будут задевать два физических сектора. Это будет приводить к разрушению производительности.

Некоторые SSD также ожидают выравнивания разделов на границы кратные 128 кБ или 1 МБ

Самый простой способ избежать проблемы с выравниванием состоит в том, чтобы сделать все начала и окончания разделов GPT выровненными на границы кратные 1 МБ. Добавьте аргумент -a 1m в ваши команды присоединения gpart.

Размер сектора ZFS

ZFS по умолчанию предполагает размер сектора 512 байт. Применение сектора файловой системы на диске с физическими 512- байтовыми секторами это прекрасно. Применением файлового сектора в 512 байт на диске с 4K секторами делает работу несколько более сложной. Предположим, вы хотите записать на такой диск 4 кБ данных. Вместо того, чтобы попросить жесткий диск записать один физический сектор, жесткому диску вначале поступает просьба изменить первую одну восьмую сектора, затем вторую восьмую часть, потом третью и так далее. Выполнение записи 512 байт в сектор 4 кБ означает чтение всего сектора 4 кБ, изменение его небольшого раздела, и запись его назад. Это намного медленнее чем простое переписывание всего сектора. Ваша производительность резко падает. Если ZFS использует сектора размера 4К на диске с секторами 512- байтовыми секторами, аппаратные средства диска будут разбивать в соответствии с размером секторов диска с очень маленькой стоимостью понижения производительности.

Хотя использование секторов бОльшего размера не влияет на производительность, это уменьшает эффективность использования пространства при сохранении множества файлов маленького размера. Если вы имеете целую пачку файлов размером в 1кБ, каждый из них займет по отдельному сектору.

Размер сектора ZFS является параметром каждого виртуального устройства в пуле. Вы не можете изменить размер сектора виртуального устройства, даже когда экспортируете пул или замещаете отказавший диск.

В их комбинации, эти два факта говорят, что почти всегда предпочтительно принудительно применять в ZFS сектора 4К, вне зависимости от того какой размер сектора сообщается лежащим в основе диском. Применение бОлшего размера сектора не нанесет серьезного урона производительности за исключением определенных специфичных для баз данных операций, причем даже в случае, когда вы на самом деле используете диски с реальными секторами 512 байт.

ZFS использует размер сектора устройства, которое сообщает о максимальном размере сектора. Если все ваши устройства заявляют об использовании 512- байтовых секторов, а вы не установите бОльший размер сектора, виртуальные диски, построенные на таких устройствах будут использовать сектора с размером 512байт. Включение в ваше VDEV хотя бы одного устройства с секторами 4096- байт принудит ZFS использовать 4096- байтовые сектора.

Не доверяйте тому, что ваши диски с секторами 4К сообщают о своем размере сектора. Сообщайте ZFS о том, чтобы она всегда принудительно применяла сектора 4К.

Переменная пула с именем ashift управляет размером сектора. Переменная 9 сообщает ZFS о необходимости использовать 512- байтовые сектора, ashift равная 12 сообщает ZFS о необходимости применять 4096- байтовые сектора. (Почему 9 и 12? 2⁹ равно 512, а 2¹² это 4096, - потому что каждый видящий "9" и понимает: 2⁹, разве не так?). Способ, которым вы устанавливаете ashift зависит от выпуска вашей FreeBSD.

Ashift во FreeBSD 10.1 и новее

Установите значение ashift в системе по умолчанию при помощи sysctl vfs.zfs.min_auto_ashift либо через /etc/sysctl.conf , либо в командной строке.

# sysctl vfs. zfs. min_auto_ashift=12

Воспользуйтесь командной строкой при установке, однако дополнительно установите навсегда sysctl vfs.zfs.min_auto_ashift, чтобы вы не забыли об этом при создании нового пула.

Данная книга предполагает, что вы применяете FreeBSD 10.1 или новее. Для более старых версий FreeBSD вам придется устанавливать ashift всякий раз вместо установки sysctl.

Ashift более ранних FreeBSD

FreeBSD версий старше 10.1 не получает ashift sysctl новых версий FreeBSD, так что вам придется полагаться на внутренний код ZFS обнаружения размера сектора. Этот код считывает размер сектора с лежащего в основе устройства хранения среднего, а именно, от поставщика хранения.

Этот случай подчеркивает критическую разницу между поставщиком и диском. FreeBSD позволяет создать сквозное устройство посредством модуля GEOM gnop(8). gnop модуль позволяет вставлять произвольные данные между вашими устройствами хранения - в данном случае, обеспечивая размер сектора. Вы можете создать gnop устройство, которое говорит, "Пропустите все прозрачно, но настаивайте на размере сектора 4096 байт." Используйте это устройство для создания zpool. В нашем случае мы добавляем устройство gnop для раздела с меткой /dev/gpt/zfs0.

# gnop create - S 4096 /dev/gpt/zfs0

Это создаст устройство /dev/gpt/zfs0.nop. Примените данного поставщика в качестве члена вашего VDEV и ZFS подхватит размер сектора для этого VDEV. Оставшаяся часть данной главы обсуждает создание различных пулов ZFS, однако, приведем пример использования этого устройства при создании зеркалированного пула.

# zpool create compost mirror gpt/zfs0.nop gpt/zfs1

Созданные при помощи gnop(8) поставщики являются временными, скрытыми при перезагрузке. Как только gnop(8) пропустит все в устройство, несмотря ни на что, ZFS обнаружит метаданные на лежащем в основе устройстве. ZFS больше не будет пытаться определять размер сектора диска, поскольку она уже установила размер сектора диска.

Создание пулов и VDEV

Создавайте пулы и виртуальные устройства одновременно при помощи zpool(8). Вы также можете применять zpool(8) для добавления VDEV в существующий пул, а также для замены отказавших устройств, но мы обсудим все это в Главе 5. Здесь мы будем создавать пулы чередования, зеркал и пулы для каждого типа устройств RAID-Z. Глава 2 обсуждает каждый тип VDEV.

Вам нужно установить ashift только один раз перед созданием необходимого вам числа пулов. Вы не должны повторно его устанавливать при каждой новой установке пула. Мы ожидаем, что большинство читателей пролистают эту книгу пока не найдут запись по тому типу пула, который они создают, поэтому мы перечисляем во всех этих записях "set ashift"

Простые устройства

Глава 0 рекомендует помечать метками диски в соответствии с их физическим расположением и номером в последовательности, чтобы вы могли легко обнаружить вышедшее из строя оборудование. На практике это очень полезно. Для книги, однако, длинные имена устройств делают восприятие материала более сложным. Наши примеры используют метки GPT из zfs и номера. Данная глава использует 6 дисков 1ТБ, причем каждый с разделом подкачки в 1 ГБ и большим разделом ZFS, создаваемыми gpart(8).

# gpart create - s gpt da0
# gpart add - a 1m - s1g - l sw0 - t freebsd- swap da0
# gpart add - a 1m - l zfs0 - t freebsd- zfs da0

Получившийся диск имеет следующие разделы.

# gpart show - l da0
=>      40  1953525088  da0  GPT  (932G)
        40        2008    -  free  -  ( 1. 0M)
      2048     2097152    1  sw0  (1. 0G)
   2099200  1951424512    2  zfs0  (931G)
1953523712        1416    -  free  -  (708K)

Мы управляем пулами ZFS при помощи меток GPT, следовательно примеры ссылаются на gpt/zfs0 и далее до gpt/zfs5. На практике пользуйтесь осмысленными метками которые соответствуют физическому расположению.

Пулы чередования

Некоторым пулам не требуется резервирование, а вместо этого им нужно очень много места. Разделы рабочих областей для инженерных или физических расчетов являются обычным случаем применения для такого типа хранилищ. Воспользуйтесь zpool create, именем пула и списком устройств в таком пуле. Не забудьте установить ashift перед созданием данного пула.

Здесь мы создаем пул из пяти поставщиков хранения.

# sysctl vfs.zfs.min_auto_ashift=12
# zpool create compost gpt/zfs0 gpt/zfs1 gpt/zfs2 gpt/zfs3 gpt/zfs4

Если ваши команды выполнились успешно, вы не получите никакого вывода. Убедитесь что пулы существуют при помощи zpool status

# zpool status
  pool: compost
 state: ONLINE
  scan: none requested
config:

NAME      STATE  READ  WRITE  CKSUM
compost   ONLINE    0      0      0
gpt/zfs0  ONLINE    0      0      0
gpt/zfs1  ONLINE    0      0      0
gpt/zfs2  ONLINE    0      0      0
gpt/zfs3  ONLINE    0      0      0
gpt/zfs4  ONLINE    0      0      0

В наличии все пять поставщиков. Каждый поставщик со своим собственным VDEV. Это большой пул для системы такого размера.

Такой пул чередует данные по всем VDEV участников, однако VDEV не имеют никакой избыточности. Большинство приложений из реального мира требуют избыточность. Простейшим видом резервирования является зеркалирование.

Пулы зеркал

Устройства зеркала копируют все данные на множество поставщиков хранения. Если один из поставщиков в зеркале отказывает, пул все еще имеет другую копию данных. Обычные зеркала имеют два диска, хотя, несомненно, можно использовать и больше. Воспользуйтесь zpool create и именем пула. Перед списком устройств хранения примените ключевое слово mirror. Установите ashift перед созданием данного пула.

# sysctl vfs.zfs.min_auto_ashift=12
# zpool create reflect mirror gpt/zfs0 gpt/zfs1

Проверьте настройки пула при помощи zpool status.

# zpool status
  pool: reflect
 state: ONLINE
  scan: none requested
config:

NAME        STATE  READ  WRITE  CKSUM
reflect     ONLINE    0      0      0
 mirror-0   ONLINE    0      0      0
  gpt/zfs0  ONLINE    0      0      0
  gpt/zfs1  ONLINE    0      0      0

errors: No known data errors

Команда zpool создает здесь новый уровень, иногда называемый mirror-0. Уровень mirror-0 является VDEV. Данный VDEV содержит два устройства, gpt/zfs0 и gpt/zfs1.

Конечно, вы можете получить зеркало со многими дисками, если это отвечает вашим потребностям. Слишком много копий точно лучше, чем недостаточно.

# zpool create reflect mirror gpt/zfs0 gpt/zfs1 gpt/zfs2 gpt/zfs3

Однако, это может быть слишком далеко заходящим примером (хотя мы обсудим разделение зеркала в несколько пулов в Мастерство FreeBSD : Расширенный ZFS).

Пулы RAID-Z

Избыточность, которую вы получаете в зеркалах, быстрая и надежная но не очень сложная или увлекающая. RAID-Z предлагает большую гибкость за счет повышения сложности, что делает его более увлекательным (Увлекательный - плохое слово для системного администрирования). Создание пула RAID-Z во многом похоже на создание других zpool: выполните zpool create и сообщите имя пула, тип и устройства хранения. Здесь мы создаем пул RAID-Z (или RAID-Z1).

# sysctl vfs.zfs.min_auto_ashift=12
# zpool create raidz1 gpt/zfs0 gpt/zfs1 gpt/zfs2

Состояние нового пула отображает новое VDEV с именем RAIDZ1-0 с тремя поставщиками.

# zpool status  bucket
  pool: bucket
 state: ONLINE
  scan: none  requested
config:

NAME        STATE  READ  WRITE CKSUM
bucket      ONLINE    0      0     0
 raidz1-0   ONLINE    0      0     0
  gpt/zfs0  ONLINE    0      0     0
  gpt/zfs1  ONLINE    0      0     0
  gpt/zfs2  ONLINE    0      0     0

Если откажет любой из дисков пула (один), данные останутся незатронутыми. Последующие уровни RAID-Z имеют еще большую избыточность. Здесь мы собираем в пул шесть поставщиков в RAIDZ-3. Единственная разница в создании RAID-Z3 и RAID-Z1 заключается в применении raidz3 и необходимости дополнительного устройства.

# zpool create bucket raidz3 gpt/zfs0 gpt/zfs1 gpt/zfs2 gpt/zfs3 gpt/zfs4 gpt/zfs5

Как вы могли догадаться на текущий момент, состояние пула отобразит новое устройство с именем RAIDZ1-0.

# zpool  status
  pool:  bucket
 state:  ONLINE
  scan:  none requested
config:
NAME        STATE  READ  WRITE CKSUM
bucket      ONLINE    0      0     0
 raidz3-0   ONLINE    0      0     0
  gpt/zfs0  ONLINE    0      0     0
  gpt/zfs1  ONLINE    0      0     0
...

Все эти пулы имеют одно VDEV. Однако, что если мы захотим множество VDEV?

Пулы множественных VDEV

Вы можете создать пул со многими VDEV. Все ключевые слова mirror, raidz, raidz2, raidz3 просят zpool(8) создать VDEV. Все перечисленные после этих ключевых слов поставщики хранения идут на создание нового экземпляра этого VDEV. При возникновении нового ключевого слова из перечисленных, zpool(8) начинает новое VDEV.

Начало данной главы обсуждало чередование по множеству зеркал, имитирующее традиционные RAID-10. Именно это мы здесь и делаем.

# sysctl vfs.zfs.min_auto_ashift=12
# zpool create barrel mirror gpt/zfs0 gpt/zfs1 mirror gpt/zfs2 gpt/zfs3

Первые три слова zpool create barrel предписывают zpool(8) создать новый экземпляр пула с именем barrel. Ключевое слово mirror предписывает "создать зеркало". Далее у нас есть два поставщика хранения, gpt/zfs0 и gpt/zfs1. Эти поставщики хранения идут в первое зеркало. Повторное появление mirror сообщает zpool(8), что предыдущее VDEV завершено и мы начинаем новое VDEV. Второе VDEV также имеет двух поставщиков хранения, gpt/zfs2 и gpt/zfs3. Состояние данного пула выглядит другим образом по сравнению со всем, что мы наблюдали до сих пор.

# zpool status barrel
  pool: barrel
 state: ONLINE
  scan: none requested
config:

NAME        STATE  READ WRITE CKSUM
barrel      ONLINE    0     0     0
 mirror-0   ONLINE    0     0     0
  gpt/zfs0  ONLINE    0     0     0
  gpt/zfs1  ONLINE    0     0     0
 mirror-1   ONLINE    0     0     0
  gpt/zfs2  ONLINE    0     0     0
  gpt/zfs3  ONLINE    0     0     0

Пул имеет два VDEVs, mirror-0 и mirror-1, причем каждое VDEV содержит два устройства хранения. Мы знаем, что ZFS чередует данные между всеми VDEV. Чередование по зеркалам является RAID-10.

Вы также можете организовывать пулы со многими VDEV, которые не имеют прямых аналогов RAID. В то время как RAID системы на основе программного обеспечения, подобные некоторым классам GEOM в FreeBSD позволяют строить вам подобные RAID, вы не сможете найти их в аппаратных платах RAID. Вот мы создаем пул, который чередует данные между двумя RAID-Z1 VDEV.

# zpool create vat raidz1 gpt/zfs0 gpt/zfs1 gpt/zfs2 raidz1 gpt/zfs3 gpt/zfs4 gpt/zfs5

Первое RAID-Z1 VDEV содержит три поставщика хранения, gpt/zfs0, gpt/zfs1 и gpt/zfs2. Второе включает gpt/zfs3, gpt/zfs4 и gpt/zfs5. zpool vat чередует данные по двум поставщикам. Это создает пул, который содержит два устройства RAID-Z.

# zpool status vat
...
config:

NAME        STATE  READ WRITE CKSUM
vat         ONLINE    0     0     0
 raidz1-0   ONLINE    0     0     0
  gpt/zfs0  ONLINE    0     0     0
  gpt/zfs1  ONLINE    0     0     0
  gpt/zfs2  ONLINE    0     0     0
 raidz1-1   ONLINE    0     0     0
  gpt/zfs3  ONLINE    0     0     0
  gpt/zfs4  ONLINE    0     0     0
  gpt/zfs5  ONLINE    0     0     0

Каждое VDEV имеет свое собственное резервирование.

Хотя зеркала и быстрее RAIDZ, вы можете обнаружить, что добавленная скорость привнесенная множественными VDEV делает такие пулы на основе RAIDZ достаточно быстрыми для вашей рабочей нагрузки при выделении вам значительно большего пространства. Единственный способ убедиться в этом- создать пул и протестировать его на рабочих нагрузках.

Запомните, что пул разделяет все запросы на запись между VDEV в пуле. Отдельный файл небольшого размера может целиком попасть на одно VDEV, однако в совокупности, записи разделяются между VDEV. Применение множества VDEV увеличивает IOPS и полосу пропускной способности.

Использование устройств журналов

Как это уже обсуждалось в Глава 2, ZFS может увеличить производительность с применением выделенных устройств кэша записи и/ или выделенных устройств кэша чтения. Такими выделенными устройствами обычно являются очень быстрые SSD с большим ресурсом перезаписи {eMLC}. Команда zpool(8) именует кэш записи log {журнал записей}, а кэш чтения {просто} cache.

Применяйте ключевые слова log и cache для определении таких устройств при создании вашего пула. Здесь мы создаем пул чередования с именем scratch с кэшами и для чтения, и для записи.

# zpool create scratch gpt/zfs0 log gpt/zlog0 cache gpt/zcache1

Устройства протокола {и кэша} отображаются в состоянии пула.

# zpool status scratch
...
config:

NAME STATE READ WRITE CKSUM
scratch ONLINE 0 0 0
 gpt/zfs0 ONLINE 0 0 0
logs
 gpt/zlog0 ONLINE 0 0 0
cache
 gpt/zcache1  ONLINE 0 0 0

В системах, которым требуется высокая доступность, вы можете строить такие кэши записи в зеркало. Зеркалированный кэш чтения не имеет смысла - если вы потеряете кэш чтения, ZFS вернется назад к чтению из реального пула. Потеря журнал записи ZIL может привести к потере данных, поэтому такое зеркалирование имеет смысл. Здесь мы создаем чередование из двух зеркал с использованием устройств с gpt/zfs0 по gpt/zfs3, с зеркалированными устройствами протоколирования gpt/zfs0 и gpt/zfs1.

# zpool create db mirror gpt/zfs0 gpt/zfs1 mirror gpt/zfs2 gpt/zfs3 log mirror gpt/zlog0 gpt/zlog1

Вы можете намеренно добавлять устройства кэширования протоколирования и чтения в некий существующий пул или удалять их из него. Если вы не уверены в необходимости повышения производительности этих устройств, попытайтесь запустить пул без них. Однако, убедитесь, что ваше оборудование имеет свободное место для добавления устройств хранения SSD позже!

Несогласованные VDEV

Не рекомендуется применение VDEV различных типов в пределах одного пула. и zpool(8) попытается предостеречь вас от подобного несчастья.

# zpool create daftie raidz gpt/zfs0 gpt/zfs1 gpt/zfs2 mirror gpt/zfs3 gpt/zfs4 gpt/zfs5
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: both raidz and mirror vdevs are present
{неверное описание vdev
применяйте '-f' для пренебрежения следующими ошибками:
несогласованный уровень репликаций: присутствуют и raidz, и mirror}

Команда zpool(8) укажет на недоразумение и затем спросит, настаиваете ли вы. Обычно мы воспринимает такие виды ошибок как способ сообщить нашему системному администратору о необходимости принять больше кофеина, но,возможно, вы делаете это намеренно. Выполнение zpool create -f с описанными типами VDEV и поставщиками хранения сообщает ZFS, что да, вы полностью осознаете намерение создания несогласованного пула. Эй, это ваша система и вы управляете ей!

Если ZFS не советует вам что-то делать, вероятно, вы не должны это делать. Когда вы применяете -f, вы создаете нечто, для чего ZFS не приспособлена. Вы легко можете создать пул, который не будет работать надлежащим образом и не может быть восстановлен.

Повторное использование поставщиков

Иногда мы создаем и уничтожаем пул более одного раза, чтобы получить правильное решение. Мы можем вынимать диски из одной машины и монтировать их в другой. Иногда мы сталкиваемся с дисками, уже использовавшимися до этого.

# zpool create db gpt/zfs1 gpt/zfs2 gpt/zfs3 gpt/zfs4
invalid vdev specification
use '-f' to override the following errors:
/dev/gpt/zfs3 is part of exported pool 'db'
{неверное описание vdev
применяйте '-f' для пренебрежения следующими ошибками:
/dev/gpt/zfs3 является частью экспортированного пула 'db'}

Мы использовали данный диск в пуле, который мы позже экспортировали (см. Главу 5) Проблемный диск применялся в этом пуле и на этом диске осталась метка ZFS. Хотя мы удалили таблицу разделов и создали ее заново, бывает, что новая таблица разделов в точности совпадает с предыдущей. В этом случае ZFS легко обнаруживает старые метаданные.

Если вы уверены, что на данном поставщике нет ничего важного, следуйте инструкциям и принудительно создайте новый пул с -f.

# zpool create -f db gpt/zfs1 gpt/zfs2 gpt/zfs3 gpt/zfs4

Программы ZFS могут быть очень придирчивы к тому, где расположены ваши флаги, поэтому убедитесь, что -f следует непосредственно за create.

Целостность пула

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

Целостность ZFS

Устройства хранения данных портятся. Если у вас есть триллионы секторов на каком-то диске, шансы того, что шальной космический луч ударет в один из них достаточно сильно, чтобы тот зашатался как пьяный - также как и шансы ошибки записи, или отказа питания, или замыкания в неисправном кабеле, или множество других возможных проблем. Никакая файловая система не может предотвратить ошибки в лежащем в ее основе оборудовании.

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

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

Если лежащие в основе VDEV имеют избыточность, ZFS либо реконструирует разрушенный блок из RAID-Z или захватывает нетронутую копию из зеркала. Если обе стороны зеркала имеют ошибки, ZFS может продолжать восстановление до тех пор, пока одни и те же данные не являются ошибочными на обоих дисках. Если VDEV не имеет резервирования, но набор данных имеет дополнительные копии этих данных, (см. Главу 4), ZFS вместо этого применяет такие дополнительные копии. Если лежащие в основе VDEV не имеют резервирования и набор данных не держит дополнительные копии, пул делает пометку,что файл поврежден и возвращает ошибку вместо возврата неверных данных. Вы можете восстановить файл из резервной копии или отбросить его.

Одновременно с проверкой целостности файлов, ZFS выполняет связи между блоками хранения. Именно эту задачу выполняет fsck(8) в традиционных файловых системах. Это небольшая часть проверки достоверности данных, и ZFS выполняет эту задачу непрерывно как часть своей обычной работы. ZVS также имеет дополнительное преимущество над fsck(8) втом, что она проверяет только действительно существующие блоки, вместо используемых и не используемых индексных дескрипторов. Если вы хотите выполнить полную проверку целостности для всех данных в пуле, выполните очистку {scrub}.

Хороший факт о проверке целостности на основе хэшей состоит в том, что она улавливает все виды ошибок, даже неожиданные. Помните, все счастливые файловые системы похожи друг на друга, каждая несчастливая файловая система несчастлива по-своему {Прим. пер.: "Анна Каренина", Часть I, Гл. I}.

Очистка ZFS

Очистка (scrub) пула ZFS проверяет все криптографические хэши каждого блока данных в пуле. Если очистка обнаруживает ошибку, она восстанавливает ее, если существует достаточная способность к их устранению. Очистка производится при работающем и используемом пуле.

Если очистка обнаружила какую- то ошибку, она будет отображена в состоянии zpool. Если вы только что выполнили очистку, вы также увидите эту информацию в строке сканирования.

...
scan: scrub repaired 0 in 15h57m with 0 errors on Sun Feb 8 15:57:55 2015
…errors: No known data errors
...

Данный пул не встретил никаких ошибок в данных, к которым он обращался. Если бы он обнаружил ошибки, он устранил бы их. Пул не должен проверять все данные на наличие ошибок, однако - он проверяет только те данные, о которых его попросили. Для методичного просмотра всего пула на предмет ошибок используйте scrub. Выполните zpool scrub с именем нужного вам пула.

# zpool scrub zroot

Очистки работают в фоновом режиме. Вы можете отслеживать их работу выполнив zpool status.

# zpool status
...
scan: scrub in progress since Tue Feb 24 11:52:23 2015
12.8G scanned out of 17.3G at 23.0M/s, 0h3m to go
0 repaired, 74.08% done
...

При очистке пула ZFS его хранилище работает намного медленнее, чем обычно. Если ваша система уже достигла своих пределов производительности, очищайте пулы только вне пределов пиковых нагрузок. Если необходимо прервать выполняющуюся очистку, исполните zpool scrub -s.

# zpool scrub -s zroot

Не забудьте вернуться и заставить систему завершить ее очистку как можно быстрее.

Частота очисток

Встроенная в ZFS проверка целостности и устойчивость к ошибкам означают, что большинство ошибок исправимо, только если они обнаружены достаточно рано, чтобы устойчивость к ошибкам вышибла ее. Это означает, что качество вашего оборудования диктует как часто вы должны выполнять очистку пулов хоста. Если ваше оборудование достаточно надежное, подобное так называемому оборудованию "серверного уровня", должно хватать ежеквартальной очистки. Если вы злоупотребляете недорогим оборудованием, вы должны выполнять очистку ежемесячно или около того.

FreeBSD может выполнять для вас регулярные очистки, как это обсуждается в "Автоматизация эксплуатации Zpool" позже в данной главе.

Свойства пула

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

Свойства пула воздействуют на весь пул. Если вы хотите установить свойство только для части пула, проверьте свойства каждого набора данных, который удовлетворяет вашим условиям.

Просмотр свойств пула

Чтобы просмотреть все свойства всех пулов в вашей системе, выполните zpool get all. Вы можете добавить в конце имя пула, если вы хотите увидеть свойства только определенного пула. Здесь мы взглянем на свойства пула zroot.

# zpool get all zroot
NAME   PROPERTY  VALUE   SOURCE
zroot  size      920G    -
zroot  capacity  1%      -
zroot  altroot   -       default
zroot  health    ONLINE  -
...

Первые две колонки дают имя пула и имя его свойства.

Третья колонка перечисляет значения свойства. Это может быть что-то типа enabled или disabled, on или off, active или inactive или же это может быть значение. Данное свойство пула size равно 920G - этот пул имеет пространство 920ГБ.

Колонка SOURCE показывает где установлено свойство. Это может быть одиночное тире, а также слова default или local. Прочерк означает, что свойство не установлено как таковое, а, скорее всего, каким-то образом считывается из пула. Вы не установите значение для размера пула или как много из его пространства используется. FreeBSD вычисляет эти значения из пула. Значение default SOURCE указывает, что это свойство установлено в свое значение по умолчанию, в то время как local означает, что это свойство специфично установлено для данного пула.

Чтобы получить отдельное свойство, выполните zpool get с именем этого совйства.

# zpool get size
NAME   PROPERTY  VALUE  SOURCE
db     size      2.72T  -
zroot  size      920G   -

Ограничивайте этот вывод заданием имени пула в конце.

Изменение свойств пула

На протяжении данной книги мы будем устанавливать свойства для изменения поведения пула. Измените свойства пула, воспользовавшись командой zpool set. Здесь мы устанавливаем свойство comment пула.

# zpool set comment="Main OS files" zroot

Теперь в рамках списка свойств появятся этот комментарий.

# zpool get comment
NAME   PROPERTY  VALUE          SOURCE
db     comment   -              default
zroot  comment   Main OS files  local

Отметим здесь колонку SOURCE. По умолчанию пул не имеет комментариев. Теперь, как только я установил комментарий, тем не менее, источник SOURCE на local. Если свойство хотя бы раз изменено с default на local, оно навсегда остается local. Даже установка свойства в значение по умолчанию не изменяет SOURCE.

# zpool set comment="-" zroot
# zpool get comment
NAME   PROPERTY  VALUE  SOURCE
db     comment   -      default
zroot  comment   -      local

Мы локально установили комментарий в значение по умолчанию, следовательно SOURCE остается span class="term">local.

Вы можете установить свойства пула во время его создания с параметром -o. Вы можете установить свойство для корневого набора данных в этом пуле при помощи -O.

# zpool create -o altroot=/mnt -O canmount=off -m none zroot /dev/gpt/disk0

Пул имеет свое свойство altroot установленным в /mnt, а корневой набор данных в этом пуле имеет свойство canmount установленное в off. Если свойство изменяет способ записи данных, это влияет только на данные, записываемые после изменения свойства. ZFS не осуществляет перезапись существующих данных для соответствия с установленным свойством.

История пула

Каждый zpool содержит копии всех изменений, произведенных с этим пулом, причем все в обратном порядке к созданию пула. Данная история не содержит событий создания. Эта история не содержит событий типа включения и выключения питания системы, однако она включает в себя установку свойств, обновления пула и создание набора данных.

Чтобы получить доступ к истории пула, запустите zpool history и присвойте имя пула.

# zpool history zroot
History for 'zroot':
2014-01-07.04:12:05 zpool create -o altroot=/mnt -O canmount=off -m none zroot mirror /dev/gpt/disk0.nop /dev/gpt/disk1.nop
2014-01-07.04:12:50 zfs set checksum=fletcher4 zroot
2014-01-07.04:13:00 zfs set atime=off zroot
...

Искушенные в FreeBSD руки, вероятно, распознали это по любому количеству руководств ZFS в документации FreeBSD и форумах.

История завершается с:

...
2015-03-12.14:36:35 zpool set comment=Main OS files zroot
2015-03-12.14:43:45 zpool set comment=- zroot

Мы изменили свойство comment, поэтому оно в истории. Навсегда.

К сожалению, история пула не отслеживает кто сделал каждое изменение, но наличие постоянной регистрации изменений помогает с анализом проблем.

Автоматизация эксплуатации Zpool

FreeBSD проверяет каждую файловую систему в системе в качестве части работы по сопровождению, выполняемой periodic(8). Вы можете добавлять информацию в эти проверки, тем самым вы получите информацию о работоспособности пула. Параметр periodic.conf daily_status_zfs_enable разрешает проверки пула.

daily_status_zfs_enable="YES"

Ежедневный вывод periodic(8) теперь содержит вывод zpool status -x, который обычно является одной строчкой "all pools are healthy".

Если вам требуется более подробная информация о вашем пуле, ежедневный отчет также может содержать вывод zpool list. Установите daily_status_zfs_zpool_list в YES для получения этого списка. Если вы хотите усекать этот вывод, отображая только состояние определенных пулов, перечислите нужные вам пулы в переменной periodic.conf daily_status_zpool.

Вы также можете заставить ZFS выполнять очистки вашего пула. При установленных параметрах очистки FreeBSD выполняет ежедневную проверку для просмотра того, нуждается ли пул в очистке, однако выполняет очистку только в установленные интервалы. Для автоматической очистки всех пулов каждые 35 дней, установите в periodic.conf daily_scrub_zfs_enable в YES.

daily_scrub_zfs_enable="YES"

FreeBSD по умолчанию должен делать очистку всех пулов. Вы не можете в явном виде исключить определенные пулы из ежедневной проверки очистки. Однако, вы можете в явном виде перечислить пулы, которые вы хотите проверять в daily_scrub_zfs_pools. Все не перечисленные пулы неочищаются.

daily_scrub_zfs_pools="zroot prod test"

Для изменения количества дней между очистками установите daily_scrub_zfs_default_threshold на нужное вам количество дней.

daily_scrub_zfs_default_threshold="10"

Если мы хотим очищать определенный пул по определенному расписанию, установите daily_scrub_zfs_${poolname}_threshold на требуемое число дней. Здесь мы очищаем пул prod каждые 7 дней.

daily_scrub_zfs_prod_threshold="7"

Все пулы с неустановленными собственными персональными порогами применяют пороговые значения, установленные по умолчанию.

Удаление пулов

Чтобы освободится от пула воспользуйтесь командой zpool destroy и именем пула.

# zpool destroy test

Уничтожение помечает лежащих в основе пула поставщиков как часть разрушенного пула. Это не удаляет диск, и всякий, кто прочитал Главу 5 сможет восстановить пул и доступ к данным.

Если вы должны безопасно удалить или переписать данные в поставщике, вам понадобится перезаписи диска или программе шрединга.

Флаги функциональности пула

ZFS и пулы изначально пришли с номером версии, указывающим поддерживаемую пулом функциональность. Система может взглянуть на незнакомого поставщика хранения и сказать: "О, это пул ZFS версии 20, так что он не поддерживает дедупликацию или естественное шифрование". Вы могли обновлять пул до последней поддерживаемой вашим выпуском версии - или нет.

Затем Oracle закрыл исходные коды ZFS, оставив различных людей с возможностью брать последний выпуск ZFS с открытым исходным кодом и поддерживать его самостоятельно.

Окончательной версией с открытым исходным кодом Oracle ZFS была версия 28. Поскольку различные группы реализовывали свою собственную функциональность, номера версий от различных групп угрожали стать несовместимыми. Различные команды ZFS могли реализовывать любую новую функциональность по своему выбору, а это означает, что, скажем, FooZFS версии 30 будет несовместима с BarZFS версии 30. Одной из основных целей ZFS является совместимость.

Команда OpenZFS решила, что лучшим путем вперед будет оторваться от отслеживания возможностей по номерам версий. Они загнули версию OpenZFS до 5000, оставив Oracle достаточно места для добавления новых версий. Чтобы приспособить всех различных разработчиков OpenZFS ко всем различным платформам, разработчики решили эффективно заменить номера версий флагами функциональности.

Изменение функциональности обычно каким-то образом изменяет формат на диске. Добавление поддержки снимков, например, означает добавление новых полей и метаданных чтобы сказать "это снимок". Система, которая не поддерживает данную функциональность взглянет на этот пул и пойдет "вот, жесть, я не распознаю эту структуру данных, я не трогаю это!" Если вы регулярно меняете диски между системами, вы захотите тщательно проверять флаги функциональности, поддерживаемые различными хостами перед обновлениями или разрешением новых флагов функциональности.

Просмотр флагов функциональности

Чтобы посмотреть флаг функциональности, поддерживаемый пулом, а также его установки, просмотрите свойства пула, которые содержат слово "feature".

# zpool get all zroot | grep feature
zroot  feature@async_destroy  enabled local
zroot  feature@empty_bpobj    active  local
zroot  feature@lz4_compress   active  local
...

Разрешенные (enabled) свойства пула доступны для применения, но в действительности не задействованы. Ваша система может поддерживать новый тип сжатия, но на самом деле не записывать никакие данные на диск с применением нового алгоритма. Этот пул может быть импортирован в систему, которая не поддерживает данную функциональность, поскольку формат диска не изменился для приспособления к данной функциональности. Новый хост не увидит ничего, что привело бы его в возбуждение.

Запрещенная (disabled) функциональность пула доступна в данной операционной системе, но не разрешена. Ничто в пуле не говорит, что эта функциональность доступна - наличие запрещенной функциональности означает, что она доступна в операционной системе. Такой пул, безусловно можно применять в хосте, который не поддерживает эту функциональность.

Если функциональность активна (active), то формат на диске изменился, поскольку функция применяется. Чаще всего это пул не может быть импортирован в систему, не поддерживающую данную функциональность. Если функция активна, но все наборы данных, использующие эту функциональность удалены, пул возвращает установку функциональности в разрешенную (enabled).

Ряд функций имеет совместимость только на чтение (read-only compatible). Если такая функциональность находится в активном применении, пул может быть частично импортирован в систему, которая не поддерживает данную функциональность. Новый хост может не видеть некоторые наборы данных в пуле и он не может записывать данные в этот пул, однако он может выделять некоторые данные из наборов данных.

Создание пула делает доступными (enabled) все функции, поддерживаемые данной реализацией ZFS операционной системы. Вы можете применить флаг -d с zpool create для запрещения всех функций в новом пуле, а затем избирательно разрешать функциональность.

Теперь, когда вы понимаете как работает пул, давайте поместим в него некие реальные данные.