Глава 23. Файловая система Z (ZFS)

Сначала создайте раздел GPT на пустом диске. Затем добавьте раздел типа freebsd-zfs, из которого создается один нерезервируемый пул:

Для просмотра нового пула ознакомьтесь с выводом команды df:

Этот вывод показывает создание и монтирование пула example, который теперь доступен как файловая система. Создайте файлы для пользователей, чтобы посмотреть, что все работает:

Этот пул пока не использует расширенные функции и свойства ZFS. Чтобы создать набор данных в этом пуле с включённым сжатием:

Набор данных example/compressed теперь представляет собой сжатую файловую систему ZFS. Попробуйте скопировать несколько больших файлов в /example/compressed.

Отключите сжатие с помощью:

Чтобы отмонтировать файловую систему, используйте zfs umount, а затем проверьте с помощью df:

Для повторного монтирования файловой системы, чтобы сделать её снова доступной, используйте zfs mount и проверьте с помощью df:

Выполнение команды mount отображает пул и файловые системы:

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

Используйте df для просмотра данных и использования пространства:

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

Чтобы уничтожить файловые системы, а затем пул, который больше не нужен:

Диски выходят из строя. Один из способов избежать потери данных при отказе диска — использование RAID. ZFS поддерживает эту возможность в своей конструкции пула. Пуллы RAID-Z требуют трёх или более дисков, но предоставляют больше полезного пространства, чем зеркальные пуллы.

Этот пример создает пул RAID-Z. Сначала на каждом диске создаются разделы GPT, затем укажите эти разделы GPT для добавления в пул с помощью ключевого слова raidz:

Предыдущий пример создал пул storage. В этом примере в этом пуле создаётся новая файловая система с именем home:

Включить сжатие и сохранить дополнительную копию каталогов и файлов:

Чтобы сделать это новым домашним каталогом для пользователей, скопируйте пользовательские данные в этот каталог и создайте соответствующие символические ссылки:

Данные пользователя теперь хранятся в только что созданном /storage/home. Проверьте это, добавив нового пользователя и войдя в систему под его учётной записью.

Создайте снимок файловой системы для последующего отката:

ZFS создаёт снимки набора данных, а не отдельного каталога или файла.

Символ @ является разделителем между именем файловой системы или тома и именем снимка. Перед удалением важного каталога создайте резервную копию файловой системы, а затем откатитесь к более раннему снимку, в котором каталог ещё существует:

Чтобы перечислить все доступные снимки, выполните команду ls в каталоге .zfs/snapshot файловой системы. Например, чтобы увидеть сделанный снимок:

Напишите скрипт для создания регулярных снимков пользовательских данных. Со временем снимки могут занимать много места на диске. Удалите предыдущий снимок с помощью команды:

После тестирования сделайте /storage/home настоящим /home с помощью следующей команды:

Выполните команды df и mount, чтобы убедиться, что система теперь распознает файловую систему как настоящий /home:

Настройка RAID-Z завершена. Для добавления ежедневных отчётов о состоянии созданных файловых систем в ночные запуски periodic(8) добавьте следующую строку в /etc/periodic.conf:

periodic(8) также может выполнять запланированные проверки пула; см. Проверка пула.

Каждый программный RAID имеет метод контроля своего состояния. Просмотр состояния устройств RAID-Z осуществляется с помощью:

Если все пулы находятся в состоянии онлайн и все работает нормально, сообщение будет следующим:

Если возникла проблема, например, диск находится в состоянии оффлайн, состояние пула будет выглядеть так:

"OFFLINE" показывает, что администратор перевел ada1p1 в автономный режим с помощью:

Выключите компьютер и замените диск ada1p1. Заново создайте GPT-раздел типа freebsd-zfs на новом диске. Включите компьютер и верните ada1p1 в пул:

Далее снова проверьте статус, на этот раз без -x, чтобы отобразить все пулы:

В этом примере все в порядке.

ZFS использует контрольные суммы для проверки целостности хранимых данных. Создание файловых систем автоматически включает их.

Проверка контрольных сумм данных (называемая scrubbing) обеспечивает целостность пула storage с помощью:

Продолжительность очистки зависит от объёма хранимых данных. Большие объёмы данных требуют пропорционально больше времени для проверки. Поскольку очистка интенсивно использует операции ввода-вывода, ZFS позволяет выполнять только одну очистку на каждом пуле одновременно. После завершения очистки просмотрите статус с помощью zpool status:

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

См. zfs(8) и zpool(8) для других опций ZFS.

Самое важное решение при создании пула хранения ZFS — это выбор типов vdev для группировки физических дисков. См. список типов vdev для получения подробной информации о возможных вариантах. Типы vdev определяют характеристики избыточности, ёмкости и производительности пула. Раскладка пула не фиксируется навсегда при его создании. Зеркала позволяют добавлять новые диски в vdev, а полосы (stripes) обновляются до зеркал путём присоединения нового диска к vdev. Vdev RAID-Z увеличиваются на один диск за раз с помощью расширения RAID-Z, которое требует OpenZFS 2.3 или более поздней версии, впервые доступной во FreeBSD 15.0. Добавление новых vdev расширяет пул в любое время, а удаление верхних уровней vdev возможно в определённых пределах. Изменение формы активного пула занимает время и пропускную способность ввода-вывода, поэтому выбор подходящих типов vdev заранее остаётся важным.

Создайте простой зеркальный пул на дисках, содержащих GPT-разделы типа freebsd-zfs:

Чтобы создать более одного vdev одной командой, укажите группы дисков, разделённые ключевым словом типа vdev, в данном примере mirror:

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

Создание пула RAID-Z2 с использованием разделов:

ZFS выравнивает и подбирает размер своих минимальных записей для каждого vdev на основе значения ashift этого vdev, которое является логарифмом размера сектора по основанию 2. OpenZFS определяет размер сектора, сообщаемый дисками при создании vdev, и выбирает ashift соответствующим образом. Некоторые диски сообщают секторы в 512 байт для совместимости, но внутренне используют секторы в 4096 байт. Создавайте пулы на таких дисках с явным параметром -o ashift=12, чтобы принудительно установить выравнивание по 4096 байт:

Установка переменной sysctl(8) vfs.zfs.vdev.min_auto_ashift в значение 12 дает тот же результат для создания пула и для последующих операций zpool add и zpool attach. ashift — это свойство каждого vdev, а не пула в целом. Оно фиксируется при создании vdev и не может быть изменено впоследствии, поэтому проверьте его перед записью данных в пул.

Уничтожьте пул, который больше не нужен, чтобы повторно использовать диски. Перед уничтожением пула необходимо размонтировать файловые системы в этом пуле. Если какой-либо набор данных используется, операция размонтирования завершится неудачей без уничтожения пула. Принудительное уничтожение пула выполняется с помощью -f. Это может привести к неопределённому поведению приложений, у которых были открыты файлы в этих наборах данных.

Подобно наборам данных, пулы имеют свойства, которые сообщают о состоянии и управляют поведением. Отобразите каждое свойство пула с помощью zpool get all mypool или укажите конкретные свойства:

Измените изменяемое свойство с помощью zpool set:

Такие свойства, как size, capacity, fragmentation и health, являются статусными значениями только для чтения. Другие изменяют поведение пула; в этой главе используется autoexpand для автоматического расширения пула (Увеличение размера пула), autoreplace с горячими резервными дисками (Горячие резервные диски и автоматическая замена с помощью zfsd), autotrim на пулах с SSD (TRIM and Initialization) и compatibility для переносимых пулов (Обновление пула дисков). Устанавливайте свойства при создании пула, передавая -o команде zpool create, как показано выше с ashift. zpoolprops(7) описывает все свойства пула.

Существует два способа добавления дисков в пул: подключение диска к существующему vdev с помощью zpool attach или добавление vdev в пул с помощью zpool add. Некоторые типы vdev позволяют добавлять диски в vdev после его создания. Виртуальные устройства (vdev) RAID-Z принимают новые диски исключительно посредством расширения RAID-Z.

Пул, созданный с одним диском, не обладает избыточностью. Он может обнаружить повреждение данных, но не может его исправить, так как нет другой копии данных. Свойство Копии (copies) может восстановить данные после небольшого сбоя, например, повреждённого сектора, но не обеспечивает такой же уровень защиты, как зеркалирование или RAID-Z. Начиная с пула, состоящего из однодискового vdev, используйте zpool attach для добавления нового диска в vdev, создавая зеркало. Также используйте zpool attach для добавления новых дисков в зеркальную группу, увеличивая избыточность и производительность чтения. При разметке дисков, используемых для пула, повторите разметку первого диска на втором. Используйте gpart backup и gpart restore для упрощения этого процесса.

Обновите однодисковый vdev (stripe) ada0p3 до зеркала, присоединив ada1p3:

Если добавление дисков к существующему vdev невозможно, альтернативным методом является добавление другого vdev в пул. Добавление vdev повышает производительность за счет распределения записей между vdev. Каждый vdev обеспечивает свою собственную избыточность. Возможно смешивание типов vdev, таких как mirror и RAID-Z, но это не рекомендуется. Добавление не избыточного vdev к пулу, содержащему mirror или RAID-Z vdev, подвергает риску данные во всем пуле. Распределение записей означает, что отказ не избыточного диска приведет к потере части каждого блока, записанного в пул.

ZFS распределяет данные по всем vdev. Например, при использовании двух зеркальных vdev это фактически эквивалентно RAID 10, где записи распределяются по двум наборам зеркал. ZFS выделяет пространство таким образом, что каждый vdev достигает 100% заполненности одновременно. Наличие vdev с разным количеством свободного места снижает производительность, так как больше данных записывается на менее заполненный vdev.

При подключении новых устройств к загрузочному пулу не забудьте обновить загрузочный код.

Присоедините вторую группу зеркал (ada2p3 и ada3p3) к существующему зеркалу:

zpool add также присоединяет выделенные устройства журнала и кэша к существующему пулу. Журнал vdev хранит журнал намерений ZFS на отдельном хранилище с низкой задержкой, ускоряя синхронные записи, такие как те, что выполняются базами данных и NFS. Зеркалируйте устройства журнала, потому что потеря незеркалированного устройства журнала вместе с сбоем системы стоит пулу последних нескольких секунд синхронных записей; см. раздел Синхронные записи, ZIL и SLOG для рекомендаций по размеру и настройке. Кэш vdev расширяет ARC вторым уровнем кэша чтения на быстром хранилище. Устройства кэша не требуют избыточности, так как ZFS вместо этого читает любой блок, который не удалось прочитать из кэша, с исходных дисков пула. Содержимое кэша, L2ARC, по умолчанию сохраняется после перезагрузки.

Добавьте зеркальный журнальный vdev и NVMe-устройство кэша к существующему пулу:

Команда zpool detach удаляет отдельные диски из зеркального виртуального устройства (vdev) при условии сохранения достаточной избыточности. Если в группе зеркала остаётся единственный диск, эта группа перестает быть зеркалом и становится страйпом, что подвергает весь пул риску в случае выхода из строя оставшегося диска.

Удалить диск из трёхдисковой зеркальной группы:

zpool remove удаляет целые vdev верхнего уровня из пула. ZFS эвакуирует vdev, копируя все выделенные ему данные на другие vdev в пуле, а затем отсоединяет диски. Удаление работает для горячих резервов, кэша, журналов, специальных и дедупликационных устройств, а также для data vdev, которые являются одиночными дисками или зеркалами. Data vdev не могут быть удалены из пулов, содержащих vdev RAID-Z верхнего уровня, и все vdev верхнего уровня в пуле должны использовать одинаковый ashift. Эвакуация выполняется в фоновом режиме, и пул остается онлайн на протяжении всего процесса; следите за прогрессом с помощью zpool status. После завершения удаления ZFS сохраняет таблицу в памяти, сопоставляющую блоки удаленного vdev с их новыми местоположениями. Таблица небольшая, но постоянная; zpool remove -n оценивает использование памяти перед началом удаления.

Удалите один из двух зеркальных vdev из пула:

Запись indirect-1 является заполнителем для переотображённых блоков удалённого vdev и не содержит дисков. Отмените выполняющееся удаление с помощью zpool remove -s.

Расширение RAID-Z увеличивает существующий vdev RAID-Z на один диск за раз, не изменяя его уровень чётности.

Чтобы расширить vdev RAID-Z, выполните zpool attach, указав имя vdev RAID-Z, как показано в zpool status, и новый диск:

Расширение перераспределяет существующие данные по увеличенному набору дисков в фоновом режиме, при этом пул остается online и используется. Добавьте -w, чтобы заставить zpool attach ожидать завершения расширения. zpool status сообщает о ходе выполнения в строке expand::

Когда расширение завершается, ёмкость нового диска становится доступной:

Блоки, записанные до расширения, сохраняют прежнее соотношение данных и чётности и продолжают занимать место соответствующим образом. Таким образом, полный прирост ёмкости от нового диска применяется к данным, записанным после расширения, тогда как старые данные выигрывают только при перезаписи, например, с помощью zfs rewrite. Повторите процедуру для увеличения vdev на несколько дисков, подключая их по одному.

dRAID — это вариант RAID-Z, который распределяет резервную емкость горячего резерва по всем дискам в vdev. dRAID vdev состоит из внутренних групп RAID-Z плюс опциональных распределенных резервов, равномерно распределенных по каждому диску. Когда диск выходит из строя, ZFS выполняет перестроение в распределенный резерв, читая и записывая на все оставшиеся диски параллельно, завершая процесс за долю времени, которое требуется для ресилверинга на один резервный диск. Замена вышедшего из строя диска затем перестраивает его из распределенного резерва, восстанавливая полную защиту. dRAID ориентирован на пулы с множеством дисков, где время перестроения RAID-Z становится опасно большим.

Тип vdev описывает полную компоновку, согласно zpoolconcepts(7):

parity — это уровень чётности внутренних групп, от 1 до 3, по умолчанию 1. data — это количество устройств данных на группу резервирования, по умолчанию 8. children — это общее количество дисков, служащее перекрестной проверкой при перечислении многих устройств. spares — это количество распределенных горячих резервов, по умолчанию 0.

Создайте пул из 24-дискового vdev dRAID с двойной четностью, 8 дисками данных на группу избыточности и 2 распределенными резервными дисками:

Распределенные запасные диски отображаются в разделе spares в zpool status, с именами вроде draid2-0-0 для первого запасного диска первого vdev.

dRAID обменивает эффективность использования пространства на скорость перестроения. В отличие от RAID-Z, dRAID использует фиксированную ширину полосы, дополняя мелкие записи нулями. При стандартных 8 дисках данных и секторах 4 КБ минимальное выделение составляет 32 КБ, что снижает полезную ёмкость и эффективность сжатия для наборов данных, где преобладают мелкие блоки. Ёмкость распределённых запасных дисков также резервируется заранее, независимо от того, произойдёт ли сбой диска когда-либо. Объединение пула dRAID со специальным vdev удерживает метаданные и мелкие блоки вне широких полос и возвращает большую часть потерянной эффективности. Для пулов с несколькими дисками RAID-Z остаётся лучшим выбором.

Специальные классы выделения привязывают vdev-устройства к конкретным типам данных пула. Vdev special хранит метаданные пула, такие как непрямые блоки и dnode, а также, опционально, блоки данных небольших файлов. Vdev dedup хранит таблицы дедупликации. Размещение этих метаданных на быстрых устройствах, таких как зеркала NVMe, ускоряет операции, требовательные к метаданным, например обход каталогов, zfs list и поиск при дедупликации в пулах, состоящих в остальном из более медленных дисков.

Добавьте зеркальный специальный vdev к существующему пулу:

Новые выделения метаданных затем направляются в специальный vdev; существующие метаданные остаются на месте, пока не будут перезаписаны.

Установка свойства special_small_blocks набора данных позволяет специальному vdev хранить блоки данных размером до указанного значения:

Допустимые значения — ноль, который отключает хранение блоков данных в специальном классе, или степень двойки от 512 байт до 1 МБ в FreeBSD 14.x; FreeBSD 15.0 принимает значения вплоть до максимального размера блока в 16 МБ. Установка этого свойства на recordsize набора данных отправляет все блоки данных этого набора данных в специальный класс. Когда специальный vdev заполняется, новые выделения перетекают обратно в обычный класс вместо сбоя.

Удаление специального или дедупликационного vdev с помощью zpool remove возможно с учётом ограничений, описанных в Добавление и удаление устройств. На практике требование соответствия ashift часто препятствует удалению, когда специальный vdev использует устройства с иным размером сектора, чем data vdev.

Статус пула важен. Если диск отключается или ZFS обнаруживает ошибку чтения, записи или контрольной суммы, соответствующий счетчик ошибок увеличивается. Вывод команды status показывает конфигурацию и состояние каждого устройства в пуле, а также состояние всего пула. Также отображаются действия, которые следует предпринять, и детали последнего scrub.

Опции подстраивают вывод под конкретную задачу:

См. zpool-status(8) для полного списка опций.

При обнаружении ошибки ZFS увеличивает счетчики ошибок чтения, записи или контрольных сумм. Чтобы очистить сообщение об ошибке и сбросить счетчики, используйте команду zpool clear mypool. Сброс состояния ошибки может быть важен для автоматизированных скриптов, которые уведомляют администратора при возникновении ошибки в пуле. Без очистки старых ошибок скрипты могут не сообщать о новых ошибках.

Может потребоваться заменить один диск на другой. При замене рабочего диска процесс сохраняет старый диск в режиме онлайн во время замены. Пул никогда не переходит в состояние деградировавшего, что снижает риск потери данных. Выполнение команды zpool replace копирует данные со старого диска на новый. После завершения операции ZFS отключает старый диск от vdev. Если новый диск больше старого, можно расширить zpool, используя новое пространство. См. Расширение пула.

Заменить работающее устройство в пуле:

На зеркальных vdev-устройствах добавление -s к zpool replace или zpool attach выполняет последовательное восстановление вместо восстанавливающего ресильверинга. Последовательное восстановление копирует данные в порядке расположения на диске без проверки контрольных сумм каждого блока, восстанавливая избыточность гораздо быстрее. Поскольку копирование пропускает проверку контрольных сумм, ZFS автоматически запускает scrub пула после завершения последовательного восстановления. Последовательное восстановление работает на зеркальных и dRAID vdev-устройствах, но не на RAID-Z. Перезапустите текущий resilver с начала с помощью zpool resilver mypool.

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

Если vdev не имеет избыточности или если устройства вышли из строя и недостаточно избыточности для компенсации, пул переходит в состояние faulted. Если недостаточно устройств для восстановления связи, пул становится неработоспособным, что требует восстановления данных из резервных копий.

При замене вышедшего из строя диска имя отказавшего диска изменяется на GUID нового диска. Новый параметр имени устройства для zpool replace не требуется, если заменяющее устройство имеет то же имя устройства.

Заменить вышедший из строя диск с помощью zpool replace:

Пулы с избыточными vdev могут регистрировать горячие резервные диски, которые находятся в режиме ожидания для замены вышедшего из строя устройства. Резервный диск должен быть не меньше устройства, которое он заменяет. Укажите резервные диски при создании пула, перечислив их после ключевого слова spare, как в zpool create mypool mirror ada0p3 ada1p3 spare ada3p3, или добавьте их в существующий пул с помощью zpool add:

Запасной диск остается неиспользуемым, отображаясь как AVAIL, пока устройство не выйдет из строя. Активируйте запасной диск вручную с помощью zpool replace, указав отказавшее устройство и запасной диск:

Запасной диск является временной мерой, и пул остается в этом состоянии, пока администратор не разрешит ситуацию. После физической замены вышедшего из строя диска и повторного зеркалирования нового устройства с помощью zpool replace, верните запасной диск в режим ожидания с помощью zpool detach mypool ada3p3. Чтобы вместо этого повысить запасной диск до постоянного члена vdev, отсоедините вышедшее из строя устройство с помощью zpool detach mypool ada1p3.

Свойство пула autoreplace, по умолчанию выключенное, управляет тем, что происходит, когда новый диск появляется в том же физическом месте, что и устройство, ранее принадлежавшее пулу. При установке autoreplace в значение on, ZFS автоматически заменяет старое устройство новым диском, не требуя команды zpool replace:

На FreeBSD автоматические реакции на сбои, включая выполнение autoreplace, выполняются zfsd(8), демоном управления отказами ZFS в базовой системе. Демон не включён по умолчанию. Включите и запустите его с помощью команды:

zfsd(8) прослушивает события пула и:

Изучите поток событий, который управляет этими решениями, с помощью zpool events. Добавление -v показывает полную полезную нагрузку каждого события, а -f оставляет команду работающей, выводя новые события по мере их поступления. ZFS также доставляет эти события в devd(8). Правила в /etc/devd/zfs.conf записывают их в системный журнал и служат шаблоном для пользовательских действий, таких как отправка почты при деградации пула.

Регулярно выполняйте scrub для пулов, желательно не реже одного раза в месяц. Операция scrub интенсивно использует диски и может снизить производительность во время выполнения. Избегайте периодов высокой нагрузки при планировании scrub или снизьте его влияние с помощью настраиваемых параметров планировщика ввода-вывода, описанных в разделе «Настройка».

Приостановите выполняющуюся проверку с помощью zpool scrub -p mypool, если она мешает другой работе; повторный запуск zpool scrub mypool возобновит её с того места, где она остановилась. Чтобы вместо этого отменить операцию проверки, выполните zpool scrub -s mypool. Команда zpool scrub -w mypool ожидает завершения проверки перед возвратом, что полезно в скриптах. Если после проверки сообщается об ошибках, zpool scrub -e mypool выполняет проверку ошибок, которая повторно проверяет только блоки с известными ошибками, завершаясь гораздо быстрее, чем полная проверка. Проверка ошибок требует OpenZFS 2.2, впервые включённого в FreeBSD 14.0.

periodic(8) может автоматически запускать проверки. Чтобы проверить каждый пул, последняя проверка которого была более 35 дней назад, добавьте эту строку в /etc/periodic.conf:

Установите daily_scrub_zfs_default_threshold="дней", чтобы изменить количество дней между проверками. periodic.conf(5) также описывает пороговые значения для отдельных пулов. Установка daily_status_zfs_enable="YES" добавляет проверку состояния пула в ежедневный отчёт periodic(8).

Контрольные суммы, хранимые с блоками данных, позволяют файловой системе самовосстанавливаться. Эта функция автоматически исправляет данные, контрольная сумма которых не совпадает с записанной на другом устройстве, входящем в состав пула хранения. Например, в конфигурации зеркала с двумя дисками, где один из дисков начинает работать со сбоями и больше не может корректно хранить данные. Это становится ещё хуже, если данные долгое время не были доступны, как в случае долгосрочного архивного хранения. Традиционные файловые системы требуют выполнения команд для проверки и исправления данных, таких как fsck(8). Эти команды занимают время, а в сложных случаях администратору приходится выбирать, какую операцию восстановления выполнить. Когда ZFS обнаруживает блок данных с несовпадающей контрольной суммой, он пытается прочитать данные с зеркального диска. Если этот диск может предоставить корректные данные, ZFS передаст их приложению и исправит данные на диске с ошибочной контрольной суммой. Это происходит без какого-либо вмешательства администратора в ходе обычной работы пула.

Следующий пример демонстрирует самовосстановление при создании зеркального пула из разделов /dev/ada0p1 и /dev/ada1p1.

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

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

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

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

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

Операция scrub читает данные с ada0p1 и перезаписывает любые данные с некорректной контрольной суммой на ada1p1, что отображается как (repairing) в выводе zpool status. После завершения операции состояние пула изменяется на:

После завершения операции очистки, когда все данные синхронизированы с ada0p1 на ada1p1, сбросьте сообщения об ошибках из состояния пула, выполнив команду zpool clear, как описано в разделе Сброс состояния ошибки.

Пулу возвращено полностью рабочее состояние, все счётчики ошибок теперь обнулены.

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

Выполните усечение одного устройства, указав его имя после пула, как в zpool trim mypool nda0p3. zpool trim -w ожидает завершения усечения, -c отменяет выполняющееся усечение, а -s приостанавливает его; повторный запуск zpool trim возобновляет приостановленное усечение. На устройствах, поддерживающих эту возможность, zpool trim --secure запрашивает безопасное усечение, при котором устройство гарантирует стирание данных, хранящихся на усечённых блоках.

zpool status -t показывает прогресс trim для каждого устройства:

Установка свойства пула autotrim в значение on заставляет ZFS непрерывно отправлять небольшие команды TRIM по мере освобождения пространства пулом:

Автоматическая утилизация пропускает небольшие освобожденные области и создает постоянную дополнительную нагрузку на устройства. Для большинства систем отключение autotrim и выполнение полной команды zpool trim по расписанию дает лучшие результаты. Начиная с FreeBSD 14.1 и более поздних версий, periodic(8) выполняет такую утилизацию ежедневно, если в /etc/periodic.conf содержится daily_trim_zfs_enable="YES".

zpool initialize является аналогом процедуры усечения: она записывает шаблон во всё нераспределённое пространство на указанных устройствах или на каждое подходящее устройство в пуле, если имена устройств не заданы. Это заставляет нижележащее хранилище выделить пространство заранее, избегая задержек при первой записи на тонко подготовленные виртуальные диски, а также проверяет новые устройства перед тем, как доверить им данные.

Как и в случае с усечением, -c отменяет инициализацию, -s приостанавливает её, а -w ожидает её завершения; -u удаляет состояние инициализации с устройств. Подробнее см. zpool-trim(8) и zpool-initialize(8).

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

Пул может хранить не более одной контрольной точки одновременно. Столбец CKPOINT команды zpool list показывает, сколько места занимает контрольная точка по мере расхождения пула с сохранённым состоянием:

Чтобы откатить изменения, экспортируйте пул и импортируйте его снова с помощью --rewind-to-checkpoint:

Перемотка (rewinding) отбрасывает все изменения, внесенные в пул после создания контрольной точки, включая более новые снимки и изменения свойств. Удалите контрольную точку, которая больше не нужна, чтобы освободить занимаемое ею пространство; -w ожидает завершения удаления:

Пока существует контрольная точка, ZFS отказывает в операциях, изменяющих структуру пула: zpool remove, zpool attach, zpool detach, zpool split и zpool reguid. Пространство, освобожденное после создания контрольной точки, не возвращается, пока контрольная точка не будет удалена, поэтому долгоживущая контрольная точка на активном пуле может заполнить его.

См. zpool-checkpoint(8) для подробностей.

Наименьшее устройство в каждом vdev ограничивает полезный размер избыточного пула. Замените наименьшее устройство на устройство большего размера. После завершения операции замены или пересинхронизации пул может расшириться для использования ёмкости нового устройства. Например, рассмотрим зеркало из диска на 1 ТБ и диска на 2 ТБ. Полезное пространство составляет 1 ТБ. При замене диска на 1 ТБ другим диском на 2 ТБ процесс пересинхронизации копирует существующие данные на новый диск. Поскольку оба устройства теперь имеют ёмкость 2 ТБ, доступное пространство зеркала увеличивается до 2 ТБ.

Пул не использует новую ёмкость автоматически по умолчанию. Установите свойство пула autoexpand в значение on перед заменой устройств, и пул увеличится, как только последнее устройство меньшего размера покинет vdev:

Иначе, начните расширение, используя zpool online -e для каждого устройства. После расширения всех устройств дополнительное пространство становится доступным для пула.

Чтобы увеличить размер vdev RAID-Z, добавив диск вместо замены существующих, см. Расширение RAID-Z.

Экспортируйте пулы перед перемещением на другую систему. ZFS отмонтирует все наборы данных, помечая каждое устройство как экспортированное, но все ещё заблокированное, чтобы предотвратить использование другими дисками. Это позволяет импортировать пулы на других машинах, операционных системах с поддержкой ZFS и даже на аппаратных архитектурах другого типа (с некоторыми оговорками, см. zpool(8)). Если в наборе данных есть открытые файлы, используйте zpool export -f для принудительного экспорта пула. Используйте эту команду с осторожностью. Наборы данных будут принудительно отмонтированы, что может привести к неожиданному поведению приложений, работавших с открытыми файлами в этих наборах данных.

Экспортируйте пул, который не используется:

Импорт пула автоматически монтирует наборы данных. Если такое поведение нежелательно, используйте zpool import -N, чтобы предотвратить это. zpool import -o устанавливает временные свойства для данного конкретного импорта. zpool import -o altroot= позволяет импортировать пул с базовой точкой монтирования вместо корня файловой системы. Если пул последний раз использовался в другой системе и не был корректно экспортирован, принудительно импортируйте его с помощью zpool import -f. zpool import -a импортирует все пулы, которые, по-видимому, не используются другой системой.

zpool-import(8) также предоставляет опции для восстановления поврежденных пулов. zpool import -F пытается откатить пул к более ранней группе транзакций, когда последние повреждены, отбрасывая последние несколько секунд записей. zpool import -m позволяет импортировать пул, у которого отсутствует выделенное устройство журнала. zpool import -o readonly=on импортирует пул в режиме только для чтения, предотвращая все записи, что полезно для анализа последствий или при спасении данных из отказывающего пула. zpool import -R /mnt объединяет altroot=/mnt с cachefile=none, сохраняя спасательный импорт от нарушения путей монтирования и кэша пулов работающей системы.

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

Импортируйте пул с альтернативным корневым каталогом:

При загрузке сценарии запуска ZFS, включённые через zfs_enable="YES" в /etc/rc.conf, импортируют каждый пул, записанный в /etc/zfs/zpool.cache. Импорт пула автоматически добавляет его в этот файл кэша; свойство пула cachefile управляет этим поведением. Пулы, импортированные с cachefile=none, не восстанавливаются автоматически после перезагрузки.

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

Пулы больше не имеют единого номера версии. Вместо этого каждое изменение формата на диске представляет собой отдельный признак (feature flag), описанный в zpool-features(7). Признак включается (enabled), когда пул разрешает его использование, и становится активным (active), как только пул сохраняет данные, зависящие от него. Включённый, но неактивный признак не влияет на совместимость. Как только признак становится активным, программное обеспечение без его поддержки больше не может импортировать пул, хотя пулы, все активные признаки которых являются «совместимыми только для чтения», всё ещё допускают импорт в режиме только для чтения.

zpool status сообщает, когда поддерживаемые возможности не включены в пуле:

Выполнение zpool upgrade без аргументов выводит список всех пулов с отключёнными возможностями:

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

Пулы, которые должны оставаться импортируемыми на системах, работающих с более старым программным обеспечением ZFS, могут ограничивать, какие возможности zpool create и zpool upgrade включают, через свойство пула compatibility:

Установка свойства на существующем пуле с помощью zpool set также работает. Каждый именованный набор функций соответствует файлу в /usr/share/zfs/compatibility.d, и значение по умолчанию off позволяет использовать все функции. Установка свойства не отключает уже включённые функции.

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

Вывод показывает команды zpool и zfs, изменяющие пул каким-либо образом, вместе с временной меткой. Команды вроде zfs list не включаются. Если имя пула не указано, ZFS отображает историю всех пулов.

zpool history может отображать ещё больше информации при использовании опций -i или -l. Опция -i показывает события, инициированные пользователем, а также внутренние события ZFS, зарегистрированные в журнале.

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

Вывод показывает, что пользователь root создал зеркальный пул с дисками /dev/ada0p1 и /dev/ada1p1. Также в каждой команде отображается имя хоста myzfsbox. Отображение имени хоста становится важным при экспорте пула с одной системы и импорте на другую. Можно различить команды, выполненные на другой системе, по имени хоста, записанному для каждой команды.

Объедините оба варианта с zpool history, чтобы получить максимально детальную информацию для любого заданного пула. История пула предоставляет ценную информацию при отслеживании выполненных действий или необходимости более детального вывода для отладки.

Встроенная система мониторинга может отображать статистику операций ввода-вывода пула в реальном времени. Она показывает объём свободного и занятого пространства в пуле, количество операций чтения и записи в секунду, а также используемую пропускную способность ввода-вывода. По умолчанию ZFS отслеживает и отображает все пулы в системе. Укажите имя пула, чтобы ограничить мониторинг только этим пулом. Простой пример:

Чтобы непрерывно отслеживать активность ввода-вывода, укажите число в качестве последнего параметра, задающее интервал в секундах между обновлениями. Следующая строка статистики выводится после каждого интервала. Нажмите Ctrl+C, чтобы остановить непрерывный мониторинг. Укажите второе число в командной строке после интервала, чтобы задать общее количество отображаемой статистики.

Отображать более детальную статистику ввода-вывода с помощью -v. Каждое устройство в пуле отображается с отдельной строкой статистики. Это полезно для просмотра операций чтения и записи, выполняемых на каждом устройстве, и может помочь определить, замедляет ли какое-либо отдельное устройство работу пула. В этом примере показан зеркальный пул с двумя устройствами:

zpool iostat предоставляет несколько более детальных представлений о конвейере ввода-вывода. -l (latency) добавляет столбцы со средней задержкой, разделяя общее время ожидания на время на диске и время, проведенное в различных очередях ввода-вывода. -q (queue) показывает количество ожидающих и активных операций в каждой очереди на vdev. -w выводит полные гистограммы задержек, а -r (request size) выводит гистограммы размеров запросов для каждого листового vdev.

Столбцы задержки в -l позволяют легко заметить один медленный диск, который замедляет работу всего vdev:

В этом примере ada2p1 требует сотни миллисекунд дискового времени для операций ввода-вывода, которые его зеркальный партнёр ada1p1 выполняет за однозначные миллисекунды, при этом оба обрабатывают схожее количество операций. Запись в зеркало завершается только после того, как завершится самый медленный участник, поэтому задержка записи всего vdev отслеживает ada2p1. Высокая задержка при нормальной работе, без ошибок чтения, записи или контрольных сумм в zpool status, часто указывает на диск, который выполняет внутренние повторы, и является кандидатом на замену.

Скрипты, которым необходимо дождаться завершения фоновой активности пула, могут блокироваться на zpool wait:

Команда возвращает управление, как только ни одно из указанных действий, таких как scrub, resilver, trim или remove, не выполняется. Полный список действий приведён в zpool-wait(8).

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

В отличие от традиционных дисков и менеджеров томов, пространство в ZFS не выделяется заранее. В традиционных файловых системах после разметки и выделения пространства невозможно добавить новую файловую систему без добавления нового диска. В ZFS создание новых файловых систем возможно в любое время. Каждый набор данных обладает свойствами, включая такие функции, как сжатие, дедупликация, кэширование и квоты, а также другие полезные свойства, такие как режим только для чтения, чувствительность к регистру, сетевое общее использование файлов и точка монтирования. Возможно вложение наборов данных друг в друга, при этом дочерние наборы данных наследуют свойства от своих родительских. Делегирование, репликация, снимки, клетки позволяют администрировать и уничтожать каждый набор данных как единое целое. Создание отдельного набора данных для каждого типа или группы файлов имеет свои преимущества. Недостатком наличия большого количества наборов данных является то, что некоторые команды, такие как zfs list, будут выполняться медленнее, а монтирование сотен или даже тысяч наборов данных замедлит процесс загрузки FreeBSD.

Создайте новый набор данных и включите для него сжатие LZ4:

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

Уничтожьте созданный набор данных:

В современных версиях ZFS команда zfs destroy выполняется асинхронно, и освобождённое пространство может появиться в пуле только через несколько минут. Используйте команду zpool get freeing poolname для просмотра свойства freeing, которое показывает, сколько места ещё остаётся освободить в фоновом режиме. Используйте команду zpool wait -t free poolname, чтобы дождаться завершения фонового освобождения. Если существуют дочерние наборы данных, например снимки или другие наборы данных, уничтожение родительского набора невозможно. Для удаления набора данных и его дочерних элементов используйте -r, чтобы рекурсивно удалить набор данных и его потомков. Опция -n -v позволяет вывести список наборов данных и снимков, которые будут удалены данной операцией, без фактического выполнения удаления. Также отображается пространство, которое будет освобождено после удаления снимков.

Том — это особый тип набора данных. Вместо монтирования в качестве файловой системы он представляется как блочное устройство в /dev/zvol/имя_пула/набор_данных. Это позволяет использовать том для других файловых систем, в качестве дисков для виртуальной машины или сделать его доступным для других сетевых узлов с использованием таких протоколов, как iSCSI или HAST.

Отформатируйте том с любой файловой системой или без файловой системы для хранения сырых данных. Для пользователя том выглядит как обычный диск. Размещение обычных файловых систем на этих zvols предоставляет возможности, которых нет у обычных дисков или файловых систем. Например, использование свойства сжатия на томе объёмом 250 МБ позволяет создать сжатую файловую систему FAT.

Создание тома резервирует в пуле достаточно места для хранения полного размера тома. Чтобы пропустить это резервирование, создайте разреженный том (sparse volume), также известный как тонко выделенный том, с помощью -s:

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

Свойство volmode управляет тем, как ZFS предоставляет том операционной системе. Установка значения full предоставляет том как провайдер GEOM с максимальной функциональностью, а geom является псевдонимом для full. Установка значения dev предоставляет том как обычный узел устройства, скрывая любые разделы, которые он содержит. Тома с volmode, установленным в none, не предоставляются за пределами ZFS вообще, но по-прежнему поддерживают снимки, клоны и репликацию, что делает их полезными в качестве целей репликации. Свойство по умолчанию имеет значение default, которое откладывается на системную настройку zvol_volmode, описанную в zfs(4).

Тома хорошо работают в качестве виртуальных дисков для виртуальных машин bhyve(8) и как хранилище для экстентов iSCSI: объявите устройство тома как LUN в ctl.conf(5) и обслуживайте его с помощью ctld(8).

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

Для изменения имени набора данных используйте zfs rename. Эту же команду можно использовать для изменения родительского набора данных. Переименование набора данных с изменением родительского набора приведёт к изменению значений свойств, унаследованных от родительского набора данных. Переименование набора данных размонтирует, а затем снова смонтирует его в новом месте (с учётом наследования от нового родительского набора данных). Чтобы предотвратить это поведение, используйте опцию -u.

Переименовать набор данных и переместить его под другой родительский набор данных:

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

Каждый набор данных ZFS имеет свойства, которые определяют его поведение. Большинство свойств автоматически наследуются от родительского набора данных, но могут быть переопределены локально. Установите свойство для набора данных с помощью zfs set свойство=значение набор_данных. Большинство свойств имеют ограниченный набор допустимых значений, zfs get отобразит каждое возможное свойство и допустимые значения. Использование zfs inherit возвращает большинство свойств к их унаследованным значениям. Также возможны пользовательские свойства. Они становятся частью конфигурации набора данных и предоставляют дополнительную информацию о наборе данных или его содержимом. Чтобы отличить эти пользовательские свойства от встроенных в ZFS, используйте двоеточие (:), чтобы создать пользовательское пространство имён для свойства.

Чтобы удалить пользовательское свойство, используйте zfs inherit с параметром -r. Если пользовательское свойство не определено ни в одном из родительских наборов данных, эта опция удаляет его (но история пула всё равно сохраняет запись об изменении).

ZFS во FreeBSD хранит ACL в стиле NFSv4 нативно; свойство набора данных acltype по умолчанию имеет значение nfsv4. Каждый файл и каталог может нести список управления доступом наряду с традиционными битами разрешений, обеспечивая более тонкий контроль, чем модель владелец/группа/остальные. Отображайте и редактируйте эти списки с помощью getfacl(1) и setfacl(1).

Отобразить ACL файла:

Предоставьте дополнительному пользователю доступ на запись, добавив запись allow:

Два свойства наборов данных управляют тем, как ACL взаимодействуют с традиционной обработкой разрешений. Свойство aclmode (discard, groupmask, passthrough или restricted) определяет, что происходит с ACL, когда chmod(1) изменяет биты разрешений файла. При значении по умолчанию, discard, chmod удаляет все записи ACL, которые не представляют новый режим файла. Свойство aclinherit (discard, noallow, restricted, passthrough или passthrough-x) определяет, какие записи ACL новые файлы и каталоги наследуют от родительского каталога. При значении по умолчанию, restricted, унаследованные записи теряют разрешения write_acl и write_owner.

Смотрите setfacl(1) и zfsprops(7) для полного синтаксиса записей и описаний свойств.

Снимки — одна из самых мощных функций ZFS. Снимок предоставляет доступную только для чтения копию набора данных на определённый момент времени. Благодаря механизму Copy-On-Write (COW), ZFS быстро создаёт снимки, сохраняя старые версии данных на диске. Если снимков не существует, ZFS освобождает место для последующего использования при перезаписи или удалении данных. Снимки экономят дисковое пространство, записывая только различия между текущим набором данных и предыдущей версией. Создание снимков возможно для целых наборов данных, но не для отдельных файлов или каталогов. Снимок набора данных дублирует всё его содержимое. Это включает свойства файловой системы, файлы, каталоги, права доступа и так далее. Снимки не занимают дополнительного места при создании, но начинают потреблять пространство по мере изменения блоков, на которые они ссылаются. Рекурсивные снимки, созданные с помощью -r, формируют снимки с одинаковыми именами для набора данных и его дочерних элементов, обеспечивая согласованный снимок файловых систем на определённый момент времени. Это может быть важно, когда приложение использует файлы в связанных наборах данных или зависящие друг от друга. Без снимков резервная копия содержала бы файлы из разных моментов времени.

Снимки в ZFS предоставляют множество функций, которых нет даже в других файловых системах с поддержкой снимков. Типичный пример использования снимков — быстрое резервное копирование текущего состояния файловой системы перед выполнением рискованных действий, таких как установка программного обеспечения или обновление системы. Если действие завершится неудачей, откат к снимку вернёт систему в состояние на момент его создания. Если обновление прошло успешно, снимок можно удалить для освобождения места. Без снимков неудачное обновление часто требует восстановления из резервных копий, что утомительно, отнимает много времени и может привести к простою системы, в течение которого она будет недоступна. Откат к снимкам выполняется быстро, даже во время обычной работы системы, с минимальным или нулевым временем простоя. Экономия времени огромна, особенно для многотерабайтных систем хранения, учитывая время, необходимое для копирования данных из резервной копии. Снимки не заменяют полное резервное копирование пула, но предлагают быстрый и простой способ сохранить копию набора данных на определённый момент времени.

Перекрестная ссылка: zfs[zfs-term-bookmark,закладка] фиксирует момент времени, в который был создан снимок, без сохранения каких-либо данных снимка. Закладки почти не занимают места на диске, независимо от того, насколько изменится набор данных впоследствии. Как и снимок, закладка может служить источником инкрементальных данных для zfs send. В отличие от снимка, она не препятствует ZFS освобождать старые данные. Такое сочетание делает закладки полезными для инкрементальной репликации: после отправки снимка на другой пул создайте закладку на нем и уничтожьте его на отправляющей стороне, освобождая место, в то время как принимающая сторона сохраняет свою копию снимка. Смотрите раздел Инкрементальные резервные копии для описания самого процесса репликации.

Создайте закладку из снимка с помощью zfs bookmark. В именах закладок в качестве разделителя между именем набора данных и именем закладки используется #, так же как в именах снимков используется @.

Перечислите закладки с помощью zfs list -t bookmark:

Когда наступает время для следующего инкрементального резервного копирования, создайте новый снимок и используйте закладку в качестве инкрементального источника:

Это работает, поскольку принимающий пул всё ещё имеет снапшот backup/data@snap1, соответствующий закладке. Закладки служат только в качестве источников для инкрементального резервирования. Смонтировать закладку, выполнить откат к ней или восстановить файлы из неё невозможно, так как она не содержит данных. Дополнительную информацию см. в zfs-bookmark(8).

Клон — это копия снимка, которая рассматривается как обычный набор данных. В отличие от снимка, клон доступен для записи, может быть смонтирован и имеет свои собственные свойства. После создания клона с помощью команды zfs clone уничтожение исходного снимка становится невозможным. Чтобы изменить отношение «родитель-потомок» между клоном и снимком, используйте команду zfs promote. Продвижение клона делает снимок потомком клона, а не исходного родительского набора данных. Это изменит способ учёта пространства в ZFS, но не повлияет на фактически используемый объём. Клон можно смонтировать в любом месте иерархии файловой системы ZFS, а не только ниже исходного расположения снимка.

Чтобы продемонстрировать функцию клонирования, используйте следующий набора данных в качестве примера:

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

Создание клона делает его точной копией состояния набора данных на момент создания снимка. Теперь можно изменять клон независимо от исходного набора данных. Связь между ними осуществляется через снимок. ZFS записывает эту связь в свойстве origin. Повышение клона с помощью zfs promote делает клон независимым набором данных. Это удаляет значение свойства origin и отключает новый независимый набор данных от снимка. Вот пример:

После внесения изменений, таких как копирование loader.conf в продвинутую клон-копию, например, старый каталог в этом случае становится устаревшим. Вместо него продвинутая клон-копия может его заменить. Для этого сначала выполните zfs destroy для старого набора данных, а затем zfs rename для клона, указав имя старого набора данных (или совершенно другое имя).

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

Блочное клонирование обеспечивает копирование при записи для отдельных копий файлов. При его включении копирование файла с помощью cp(1) не дублирует данные файла. Вместо этого новый файл ссылается на те же блоки, что и оригинал, и ZFS записывает новые блоки только тогда, когда впоследствии изменяется один из файлов. cp(1) выполняет копирование с помощью copy_file_range(2), которое ZFS превращает в операции блочного клонирования, делая копии внутри пула практически мгновенными и изначально не потребляющими дополнительное пространство.

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

Блочное клонирование требует возможности пула block_cloning из OpenZFS 2.2, впервые выпущенной в FreeBSD 14.0 (см. zpool-features(7)). Управляющая системная переменная sysctl(8) vfs.zfs.bclone_enabled определяет, создаёт ли ZFS блочные клоны на самом деле. По умолчанию она равна 0 в FreeBSD 14.x и 1 в FreeBSD 15.0. Пока sysctl равен 0, copy_file_range() возвращается к обычному копированию. Чтобы включить блочное клонирование в FreeBSD 14.x:

Чтобы сохранить эту настройку после перезагрузок, добавьте следующую строку в /etc/sysctl.conf:

Свойства пула bcloneused, bclonesaved и bcloneratio показывают пространство, используемое клонированными блоками, пространство, сэкономленное за счёт клонирования, и результирующий коэффициент экономии:

Хранение данных в единственном пуле в одном месте подвергает их рискам, таким как кража, стихийные бедствия или действия людей. Регулярное резервное копирование всего пула крайне важно. ZFS предоставляет встроенную функцию сериализации, которая может отправлять потоковое представление данных на стандартный вывод. Используя эту функцию, можно сохранять эти данные в другом пуле, подключённом к локальной системе, или отправлять их по сети на другую систему. Снимки являются основой для этой репликации (см. раздел о снимках ZFS). Команды, используемые для репликации данных, — это zfs send и zfs receive.

Эти примеры демонстрируют репликацию ZFS с использованием следующих двух пулов:

Имя пула mypool — это основной пул, в который данные регулярно записываются и откуда они читаются. Используйте второй резервный пул backup на случай, если основной пул станет недоступен. Обратите внимание, что этот переход на резервный пул не выполняется автоматически в ZFS, а должен быть осуществлён вручную системным администратором при необходимости. Используйте снимок (snapshot), чтобы обеспечить согласованную версию файловой системы для репликации. После создания снимка mypool скопируйте его в пул backup путём репликации снимков. Это не включает изменения, сделанные после последнего снимка.

Теперь, когда снимок существует, используйте zfs send для создания потока, представляющего содержимое снимка. Сохраните этот поток в файл или примите его в другом пуле. Поток записывается в стандартный вывод, но перенаправьте его в файл или канал, иначе появится ошибка:

Для резервного копирования набора данных с помощью zfs send перенаправьте вывод в файл, расположенный в подключённом пуле резервных копий. Убедитесь, что в пуле достаточно свободного места для размещения отправленного снимка, то есть для данных, содержащихся в снимке, а не для изменений по сравнению с предыдущим снимком.

Команда zfs send передала все данные из снимка backup1 в пул backup. Для автоматического создания и отправки таких снимков используйте задание cron(8).

Вместо хранения резервных копий в виде архивных файлов ZFS может получать их как активную файловую систему, обеспечивая прямой доступ к резервным данным. Для доступа к фактическим данным, содержащимся в этих потоках, используйте zfs receive, чтобы преобразовать потоки обратно в файлы и каталоги. В приведённом ниже примере объединяются zfs send и zfs receive с использованием конвейера для копирования данных из одного пула в другой. После завершения передачи данные можно использовать напрямую в целевом пуле. Реплицировать набор данных можно только в пустой набор данных.

Используйте Квоты наборов данных, чтобы ограничить объём пространства, используемого определённым набором данных. Референтные квоты работают схожим образом, но учитывают пространство, используемое самим набором данных, исключая снимки и дочерние наборы данных. Аналогично, используйте пользовательские и групповые квоты, чтобы предотвратить исчерпание всего пространства в пуле или наборе данных пользователями или группами. Квоты проектов, описанные ниже, ограничивают занимаемое пространство для произвольного дерева каталогов.

Следующие примеры предполагают, что пользователи уже существуют в системе. Перед добавлением пользователя в систему убедитесь, что вы сначала создали его домашний набор данных и установили mountpoint в /home/bob. Затем создайте пользователя и укажите домашний каталог на расположение mountpoint набора данных. Это правильно установит права владельца и группы без перекрытия уже существующих путей домашних каталогов.

Чтобы установить квоту набора данных в 10 ГБ для storage/home/bob:

Чтобы установить контрольную квоту в 10 ГБ для storage/home/bob:

Удалить квоту в 10 ГБ для storage/home/bob:

Общий формат userquota@пользователь=размер, и имя пользователя должно быть в одном из следующих форматов:

Например, чтобы установить пользовательскую квоту в 50 ГБ для пользователя с именем joe:

Чтобы удалить любую квоту:

Общий формат для установки квоты группы: groupquota@группа=размер.

Чтобы установить квоту для группы firstgroup в 50 ГБ, используйте:

Чтобы удалить квоту для группы firstgroup или убедиться, что она не установлена, используйте вместо этого:

Как и в случае с пользовательскими квотами, пользователи без прав root могут видеть квоты, связанные с группами, к которым они принадлежат. Пользователь с привилегией groupquota или root может просматривать и устанавливать квоты для всех групп.

Для отображения объёма пространства, используемого каждым пользователем в файловой системе или снимке, вместе с квотами, используйте zfs userspace. Для информации о группах используйте zfs groupspace. Подробнее о поддерживаемых опциях или о том, как отобразить только определённые опции, см. в zfs-userspace(8).

Привилегированные пользователи и root могут просмотреть квоту для storage/home/bob, используя:

Резервирования гарантируют всегда доступный объём пространства в наборе данных. Зарезервированное пространство не будет доступно для других наборов данных. Эта полезная функция обеспечивает наличие свободного места для важных наборов данных или файлов журналов.

Общий формат свойства reservation — reservation=размер, поэтому, чтобы установить резервирование в 10 ГБ для storage/home/bob, используйте:

Чтобы очистить любое резервирование:

Тот же принцип применяется к свойству refreservation для установки Референсного резервирования, с общим форматом refreservation=размер.

Эта команда показывает все и резервирования (reservation), и референсные резервирования (refreservation), существующие в storage/home/bob:

ZFS предоставляет прозрачное сжатие. Сжатие данных на уровне блоков экономит место и увеличивает пропускную способность диска. Если данные сжимаются на 25%, то сжатые данные записываются на диск с той же скоростью, что и несжатые, что приводит к эффективной скорости записи в 125%. Сжатие также может быть отличной альтернативой Дедупликации, так как не требует дополнительной памяти.

ZFS предлагает различные алгоритмы сжатия, каждый со своими компромиссами. В OpenZFS 2.2 и новее для вновь создаваемых пулов и наборов данных по умолчанию установлено значение compression=on, которое выбирает алгоритм LZ4. Сжатие LZ4 позволяет сжимать весь пул без значительного снижения производительности, характерного для других алгоритмов. Главное преимущество LZ4 — функция раннего прерывания. Если LZ4 не достигает как минимум 12,5% сжатия в заголовочной части данных, ZFS записывает блок без сжатия, чтобы избежать потерь процессорного времени на попытки сжать уже сжатые или несжимаемые данные. Изменение свойства compression влияет только на новые записи; существующие данные сохраняют свою старую кодировку до тех пор, пока не будут перезаписаны (см. «Перезапись существующих данных»). Подробнее о различных алгоритмах сжатия, доступных в ZFS, см. в разделе Сжатие терминологии.

Администратор может оценить эффективность сжатия, используя свойства набора данных.

Набор данных использует 449 ГБ пространства (свойство used). Без сжатия он занял бы 496 ГБ пространства (свойство logicalused). Это даёт коэффициент сжатия 1.11:1.

Сжатие может иметь неожиданный побочный эффект при использовании вместе с Квотами пользователей. Квоты пользователей ограничивают фактическое пространство, которое пользователь занимает на наборе данных после сжатия. Если у пользователя есть квота в 10 ГБ, и он записывает 10 ГБ сжимаемых данных, он всё равно сможет сохранить больше данных. Если позже пользователь обновит файл, например базу данных, более или менее сжимаемыми данными, количество доступного ему пространства изменится. Это может привести к необычной ситуации, когда пользователь не увеличил фактический объём данных (свойство logicalused), но изменение степени сжатия привело к достижению предела его квоты.

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

В OpenZFS 2.0 был добавлен алгоритм сжатия Zstandard (Zstd). Zstd обеспечивает более высокие коэффициенты сжатия по сравнению с используемым по умолчанию LZ4, при этом работая значительно быстрее альтернативного gzip.

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

Даже при частом обновлении данных включение сжатия часто обеспечивает более высокую производительность. Одно из главных преимуществ связано с функцией сжатого ARC. Адаптивный кэш замещения (ARC Adaptive Replacement Cache) в ZFS хранит сжатую версию данных в оперативной памяти, распаковывая их при каждом обращении. Это позволяет хранить больше данных и метаданных в том же объёме памяти, повышая коэффициент попадания в кэш.

ZFS предлагает 19 уровней сжатия Zstd, каждый из которых обеспечивает постепенное увеличение экономии места в обмен на более медленное сжатие. Уровень по умолчанию — zstd-3, который обеспечивает лучшее сжатие, чем LZ4, без значительного снижения скорости. Уровни выше 10 требуют большого объёма памяти для сжатия каждого блока, и системы с менее чем 16 ГБ ОЗУ не должны их использовать. ZFS также использует подмножество уровней Zstd fast, которые работают быстрее, но обеспечивают меньшую степень сжатия. ZFS поддерживает уровни от zstd-fast-1 до zstd-fast-10, от zstd-fast-20 до zstd-fast-100 с шагом 10, а также zstd-fast-500 и zstd-fast-1000, которые обеспечивают минимальное сжатие, но обладают высокой производительностью.

Если ZFS не может получить необходимую память для сжатия блока с помощью Zstd, он переходит к сохранению блока в несжатом виде. Это маловероятно, за исключением случаев использования максимальных уровней Zstd на системах с ограниченной памятью. ZFS подсчитывает, сколько раз это произошло с момента загрузки модуля ZFS, с помощью kstat.zfs.misc.zstd.compress_alloc_fail.

Свойства, такие как compression, checksum, dedup и copies, влияют только на вновь записываемые данные. Их изменение оставляет существующие блоки сохранёнными как есть, и применение новых значений традиционно требовало цикла отправки/получения или копирования каждого файла туда и обратно. zfs rewrite вместо этого перезаписывает блоки существующих файлов на месте, как если бы они были атомарно прочитаны и записаны обратно, поэтому текущие значения свойств вступают в силу без этих обходных путей.

Команда работает с файлами и каталогами, а не с именами наборов данных. Чтобы применить вновь выбранный алгоритм сжатия ко всему набору данных, выполните рекурсивный обход от его точки монтирования:

Добавление -v выводит имя каждого перезаписанного файла. -x предотвращает переход рекурсии через точки монтирования в дочерние наборы данных, а -o и -l ограничивают перезапись диапазоном байт внутри файла. Изменения свойств, которые могли бы изменить логический размер блока, такие как recordsize, не влияют на перезаписанные файлы.

Переписанные блоки — это новые блоки: снимки, сделанные до перезаписи, продолжают ссылаться на старые копии, поэтому использование дискового пространства может расти, пока эти снимки не будут уничтожены. zfs rewrite не работает через снимки по той же причине. Подробности см. в zfs-rewrite(8).

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

dedup является свойством набора данных, а не свойством пула. Чтобы активировать дедупликацию, установите это свойство на наборе данных:

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

Дедупликация затрагивает только новые данные, записываемые в набор данных. Простое включение этой опции не приведёт к дедупликации уже записанных данных. В FreeBSD 15.0 zfs rewrite позволяет перезаписать существующие данные так, чтобы они прошли через дедупликацию. Пул с только что активированным свойством дедупликации будет выглядеть следующим образом:

Столбец DEDUP показывает фактический уровень дедупликации для пула. Значение 1.00x означает, что данные пока не дедуплицированы. В следующем примере некоторые системные двоичные файлы копируются три раза в разные каталоги в пуле с дедупликацией, созданном выше.

Для наблюдения за дедупликацией избыточных данных используйте:

Столбец DEDUP показывает коэффициент 3.00x. Обнаружение и дедупликация копий данных используют треть пространства. Потенциальная экономия пространства может быть огромной, но достигается за счет наличия достаточного объёма памяти для отслеживания дедуплицированных блоков. ZFS хранит запись для каждого дедуплицированного блока в таблице дедупликации (DDT). Эмпирическое правило гласит, что требуется 5–6 ГБ оперативной памяти на 1 ТБ дедуплицированных данных. Когда таблица перестаёт помещаться в памяти, каждая запись вынуждает считывать элементы таблицы с диска, и производительность резко падает.

Дедупликация не всегда полезна, если данные в пуле не содержат избыточности. ZFS может показать потенциальную экономию пространства, имитируя дедупликацию на существующем пуле:

После завершения анализа пула командой zdb -S отображается коэффициент сокращения пространства, который был бы достигнут при активации дедупликации. В данном случае значение 1.16 указывает на низкий уровень экономии пространства, в основном обеспечиваемый сжатием. Активация дедупликации для этого пула не сэкономит значительного объёма пространства и не оправдает объём памяти, необходимый для её включения. Используя формулу ratio = dedup * compress / copies, системные администраторы могут планировать распределение хранилища, определяя, будет ли рабочая нагрузка содержать достаточное количество дублирующихся блоков, чтобы оправдать требования к памяти. Если данные достаточно хорошо сжимаемы, экономия пространства может быть значительной.

Быстрое дедуплицирование, переработанная реализация, снижающая эти затраты, требует OpenZFS 2.3 или более поздней версии, впервые доступной в FreeBSD 15.0. Быстрое дедуплицирование группирует обновления таблицы дедупликации в журнале на диске и сбрасывает их в таблицу в фоновом режиме, снижая случайный ввод-вывод, из-за которого классическая дедупликация была медленной. Свойство пула dedup_table_quota задаёт ограничение на размер таблицы на диске; ZFS прекращает добавлять новые записи, когда пул достигает лимита, а при значении по умолчанию auto размер выделенного vdev для дедупликации служит квотой. Свойство пула dedup_table_size, доступное только для чтения, сообщает текущий размер таблицы. zpool ddtprune -p 30 pool удаляет самые старые 30% записей таблицы, которые не дают экономии, поскольку на них ссылается только один блок; -d days вместо этого удаляет записи с одной ссылкой, старше указанного количества дней. zpool status -DD pool отображает статистику таблицы дедупликации, включая гистограмму блоков по количеству ссылок. Хранение таблицы на выделенном для дедупликации vdev, состоящем из быстрых устройств, обеспечивает быстрый поиск даже когда таблица превышает объём оперативной памяти.

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

Используйте zfs jail и соответствующее свойство jailed, чтобы делегировать набор данных ZFS в Клетку. zfs jail идентификатор_клетки присоединяет набор данных к указанной клетке, а zfs unjail отсоединяет его. Для управления набором данных изнутри клетки установите свойство jail. ZFS запрещает монтирование на хосте набора данных со свойством jail, так как его точки монтирования могут нарушить безопасность хоста.

Делегированный набор данных передает управление всем поддеревом администратору клетки, который может монтировать его, создавать дочерние наборы данных, делать снимки и изменять свойства, все это ограничено этим поддеревом. Для этого клетке необходимо включить параметры allow.mount и allow.mount.zfs, а параметр enforce_statfs установить на значение ниже 2. Обратитесь к jail(8) за подробностями об этих параметрах.

Этот пример создаёт набор данных, помечает его как находящийся в клетке и прикрепляет его к запущенной клетке myjail:

Затем набор данных появляется в zfs list внутри клетки и доступен для управления там. zfs unjail myjail mypool/jaildata возвращает управление хосту. Дополнительную информацию см. в zfs-jail(8).

Начиная с FreeBSD 15.0, jail(8) автоматизирует подключение. Укажите наборы данных для делегирования в параметре клетки zfs.dataset, и jail(8) подключает их при запуске клетки. Наборы данных уже должны иметь установленный параметр jailed=on, а параметр требует allow.mount.zfs. Запись в /etc/jail.conf с его использованием выглядит так:

Установка параметра клетки zfs.mount_snapshot в значение 1 дополнительно позволяет пользователям внутри клетки получать доступ к содержимому снимков ZFS в каталоге .zfs делегированных файловых систем.

zfs allow someuser create mydataset предоставляет указанному пользователю разрешение на создание дочерних наборов данных в выбранном родительском наборе данных. Важное замечание: создание нового набора данных включает его монтирование. Для этого необходимо установить параметр vfs.usermount в sysctl(8) FreeBSD в значение 1, чтобы разрешить непривилегированным пользователям монтировать файловую систему. Ещё одно ограничение, направленное на предотвращение злоупотреблений: непривилегированные пользователи должны быть владельцами точки монтирования, куда монтируется файловая система.

zfs allow someuser allow mydataset предоставляет указанному пользователю возможность назначать любые разрешения, которые у него есть для целевого набора данных или его дочерних элементов, другим пользователям. Если пользователь имеет разрешение snapshot и разрешение allow, он может предоставить разрешение snapshot другим пользователям.

Шифрование ZFS включается путем установки свойства encryption=on при создании набора данных. Установка этого свойства вне команды zfs create не включает шифрование задним числом, поскольку оно действует только во время создания набора данных. В следующем примере для монтирования зашифрованного набора данных после его создания используется парольная фраза.

Если парольная фраза короче восьми символов, ZFS отклоняет её и не создаёт набор данных. После того как парольная фраза была введена правильно дважды, ZFS создаёт и монтирует набор данных в пуле.

Любые данные, хранящиеся в зашифрованном наборе данных, остаются зашифрованными, пока они там находятся. Копирование данных из зашифрованного набора данных в незашифрованное место расшифровывает данные во время операции копирования. Затем вновь созданный набор данных можно при необходимости смонтировать в другом месте.

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

Перечисление свойств собственного шифрования ZFS для набора данных выполняется с помощью следующей команды:

Свойство encryption показывает aes-256-gcm, который в настоящее время является методом шифрования, используемым ZFS по умолчанию. Как указано в столбце SOURCE, ни это свойство, ни свойство keyformat нельзя изменить с помощью zfs set после создания набора данных. Смотрите раздел изменение ключа шифрования для получения информации о том, как изменить некоторые из этих свойств. В следующей таблице перечислены свойства, связанные с шифрованием, используемые ZFS:

Защита данных, хранящихся в зашифрованном наборе данных, требует двух шагов: сначала размонтировать набор данных, затем выгрузить ключ шифрования из памяти. Это различие важно. Размонтированный набор данных не защищён, если его ключ шифрования остаётся загруженным в памяти. Всегда выполняйте zfs unload-key, чтобы защитить данные. Чтобы снова получить доступ к набору данных, загрузите ключ и укажите парольную фразу, как описано в разделе загрузка ключа шифрования. ZFS предотвращает выполнение zfs unload-key, пока набор данных всё ещё смонтирован.

Выполнение zfs unload-key несколько раз приводит к ошибке, указывающей на то, что ключ уже был выгружен.

Прежде чем зашифрованный набор данных можно будет использовать, как и любой другой набор данных, необходимо загрузить его ключ шифрования и указать парольную фразу. На этом этапе свойство keystatus по-прежнему имеет значение unavailable, и монтирование набора данных завершается ошибкой, поскольку ключ ещё не был загружен:

Это указывает на то, что набор данных зашифрован и требует ключ шифрования. Чтобы смонтировать набор данных, выполните zfs load-key и введите парольную фразу при появлении запроса:

Затем смонтируйте набор данных, чтобы сделать его доступным через иерархию файловой системы:

Чтобы рекурсивно загрузить несколько ключей шифрования, укажите параметр -r с командой zfs load-key. Если ключ уже был загружен, ZFS сообщает об этом сообщением об ошибке.

Свойство keystatus также подтверждает, что ключ был загружен, сообщая значение available. Чтобы проверить, корректен ли пароль, не загружая ключ, используйте параметр -n для выполнения пробного запуска.

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

Выполнение zfs change-key требует, чтобы текущий ключ был загружен. Если он не загружен, ZFS всё равно запросит новый ключ, но затем выведет предупреждение о том, что текущий ключ не был загружен.

Команда zfs change-key также может изменять свойства keylocation, keyformat и pbkdf2iters, указывая их с помощью опции -o. Выполнение zfs change-key над зашифрованным дочерним набором данных делает его корнем шифрования, если он еще не является таковым. Чтобы предотвратить такое поведение и продолжить наследование ключа родительского набора, укажите опцию -i.

Имейте в виду, что смена ключа шифрования родительского набора данных также меняет ключ для дочерних наборов данных, которые его наследуют. Следовательно, эти дочерние наборы данных продолжают использовать ключ шифрования родителя. Если дочерний набор данных должен использовать другой ключ, либо укажите другой keyformat при его создании, либо выполните zfs change-key для дочернего набора данных. Это создаст новый корень шифрования для дочернего элемента и разорвёт его наследование шифрования от родителя.

Клоны ZFS зашифрованного набора данных всегда используют ключ шифрования своего исходного набора данных. В результате свойства keystatus, keyformat, keylocation и pbkdf2iters не наследуются, как другие свойства набора данных. Вместо этого они используют значения, определённые корнем шифрования. Чтобы определить корень шифрования, используйте свойство encryptionroot только для чтения.

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

Если мастер-ключ был скомпрометирован, предпочтительным решением является безопасное стирание нижележащих устройств хранения и создание нового пула. После этого восстановите данные из резервной копии в новый пул. Или создайте новый зашифрованный набор данных, перенесите данные с помощью zfs send и zfs receive, а затем выполните zpool trim --secure, чтобы стереть освободившееся пространство. Если нижележащее оборудование не поддерживает безопасный TRIM, вместо этого используйте zpool initialize.

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

В дополнение к отправке зашифрованных резервных копий через SSH, использование опции -w (raw) с командой zfs send передает зашифрованные блоки данных в целевой пул. Сырая отправка обеспечивает несколько преимуществ:

Чтобы отправить созданный выше снимок в виде необработанного потока в набор данных secret в пуле backup, введите следующую команду:

Без опции -w команда zfs send передает данные в незашифрованном виде. Принимающая система затем может повторно зашифровать данные, используя другой ключ. Однако это предотвращает будущие инкрементальные «сырые» отправки на это место назначения.

Скрипт zfskeys из rc(8) загружает ключи шифрования при загрузке для зашифрованных наборов данных, чьё свойство keylocation указывает на файл ключа с URL-адресом file://. Скрипт запускается после импорта пула и перед монтированием файловых систем, поэтому наборы данных, обрабатываемые таким образом, монтируются автоматически во время обычного запуска ZFS. Скрипт не обрабатывает наборы данных с keylocation=prompt; загружайте их ключи вручную с помощью zfs load-key после загрузки системы.

Чтобы переключить набор данных, созданный ранее, с парольной фразы на файл ключа, сгенерируйте 32 байта случайных данных в качестве нового ключа, ограничьте доступ к файлу ключа и измените ключ шифрования набора данных:

Включите скрипт в файле /etc/rc.conf:

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

Загрузочное окружение содержит только наборы данных в zroot/ROOT. В стандартной компоновке Root-on-ZFS это включает всю корневую файловую систему с /usr/local и /var/db, поэтому установленные пакеты и их метаданные откатываются вместе с операционной системой. Наборы данных за пределами zroot/ROOT, такие как zroot/home, zroot/var/log и zroot/var/mail, являются общими: каждое окружение видит одни и те же файлы, и активация более старого окружения не возвращает их в более раннее состояние.

Спланируйте структуру набора данных с учётом этого разделения до того, как полагаться на загрузочные окружения. Данные, которые должны пережить откат, например базы данных приложения, установленного из пакетов, должны находиться в собственном наборе данных вне zroot/ROOT:

При такой компоновке откат к более старой среде возвращает бинарные файлы сервера баз данных к их предыдущей версии, в то время как содержимое базы данных остается нетронутым. Обратное также верно: файлы, записанные в общие наборы данных при тестировании новой среды, сохраняются после переключения обратно, поэтому загрузочные среды не заменяют снимки этих наборов данных.

Отрегулируйте параметры настройки, чтобы ZFS показывал наилучшую производительность для различных рабочих нагрузок. FreeBSD предоставляет параметры ядра ZFS как переменные sysctl(8) в разделе vfs.zfs; zfs(4) документирует каждый параметр и его значение по умолчанию. Установите значения, которые должны применяться с момента загрузки, в /boot/loader.conf; изменяйте значения, доступные для изменения во время работы, с помощью sysctl(8) и сделайте их постоянными в /etc/sysctl.conf.

ZFS хранит недавно и часто используемые данные и метаданные в оперативной памяти в ARC. ARC растет по мере необходимости до vfs.zfs.arc.max и снова уменьшается, когда другим программам нужна память, поэтому на выделенном сервере хранения нормально, что большая часть оперативной памяти используется. ARC хранит блоки в их сжатом виде на диске и распаковывает их при доступе. Этот сжатый ARC позволяет тому же объему оперативной памяти кэшировать больше данных, увеличивая эффективную частоту попаданий.

top(1) отображает текущий размер ARC в строке сводки по памяти. Дерево kstat.zfs.misc.arcstats из sysctl(8) предоставляет подробную статистику, включая текущий размер, целевой максимум, а также счетчики попаданий и промахов:

filesystems/zfs-stats обобщает эти статистические данные в удобочитаемом отчете.

ARC возвращает память при нехватке ресурсов, но на системах, где ОЗУ разделяется между ZFS и другими крупными потребителями, такими как базы данных, виртуальные машины или клетки, конкуренция может вызывать неравномерную производительность с обеих сторон. Ограничение ARC оставляет предсказуемый объём памяти для других рабочих нагрузок. Например, чтобы ограничить ARC до 8 ГБ, добавьте эту строку в /boot/loader.conf:

Изменение vfs.zfs.arc.max с помощью sysctl(8) вступает в силу немедленно, хотя уменьшение теплого ARC освобождает память постепенно.

Каждый пул имеет ZIL. Приложения, запрашивающие синхронную семантику с помощью fsync(2) или флага O_SYNC, не получают подтверждение до тех пор, пока ZFS не зафиксирует соответствующую запись журнала намерений в стабильном хранилище. По умолчанию ZIL располагается на обычных vdev пула, поэтому каждая синхронная запись конкурирует с обычным вводом-выводом пула. Асинхронные записи обходят ZIL и записываются со следующей транзакционной группой.

Выделенный перекрестная ссылка:zfs[zfs-term-vdev-log,log] vdev, часто называемый SLOG (отдельный журнал), перемещает ZIL на быстрое устройство:

SLOG помогает только рабочим нагрузкам, которые генерируют много синхронных записей, например, NFS-серверам и базам данных. Для чисто асинхронных рабочих нагрузок он не имеет значения.

Несколько гигабайт ёмкости SLOG вполне достаточно: ZIL хранит максимум несколько секунд входящих записей, примерно объём одной группы транзакций, прежде чем ZFS запишет данные в их конечное расположение в пуле. Выбирайте SSD с защитой от потери питания и низкой задержкой устойчивой записи, а также зеркалируйте устройства журнала. ZFS читает ZIL только после сбоя, поэтому потеря незеркалированного SLOG вместе со сбоем системы приводит к потере записей, которые были подтверждены, но ещё не зафиксированы в пуле.

Свойство sync набора данных управляет поведением синхронной записи:

Свойство logbias регулирует, как ZFS использует журнал: logbias=latency (по умолчанию) предпочитает SLOG для минимизации задержки фиксации, тогда как logbias=throughput записывает синхронные данные напрямую в основной пул, оставляя ёмкость SLOG для наборов данных, чувствительных к задержке. Подробности см. в zfsprops(7).

Свойство набора данных direct управляет тем, как ZFS обрабатывает запросы, сделанные с флагом O_DIRECT:

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

ZFS по-прежнему проверяет контрольные суммы для прямых чтений и записей, поэтому защита целостности данных не изменяется. Прямые записи должны быть выровнены по значению recordsize набора данных; ZFS незаметно перенаправляет невыровненную часть запроса через ARC. См. zfsprops(7) для получения полных правил и ограничений по выравниванию.

Свойство recordsize задаёт наибольший блок, который ZFS использует для хранения файла в наборе данных, по умолчанию 128 КБ. Согласование размера блока с шаблоном ввода-вывода рабочей нагрузки позволяет избежать чтения и записи большего объёма данных, чем запрашивает приложение.

Для баз данных, выполняющих небольшие случайные чтения и записи, установите recordsize равным размеру страницы базы данных, обычно 8 КБ или 16 КБ, до создания файлов базы данных. Для наборов данных, хранящих большие медиафайлы или потоки резервных копий, которые читаются и записываются последовательно, recordsize=1M снижает накладные расходы на метаданные и улучшает сжатие. Тома используют свойство volblocksize вместо этого, которое по умолчанию составляет 16 КБ и не может быть изменено после создания тома.

Изменение recordsize влияет только на новые записанные файлы; существующие файлы сохраняют свой исходный размер блока. Даже zfs rewrite не применяет новое значение recordsize к существующим файлам, поскольку изменения свойств, влияющие на логический размер блока, не действуют на перезаписанные блоки; скопируйте файлы заново, чтобы сохранить их с новым значением.