Файловая система ZFS — различия между версиями

Текущая версия на 07:11, 24 апреля 2016

ZFS пришла в мир Linux из операционной системы Solaris. Её возможности выходят за рамки рядовых файловых систем и подробно рассмотрены в документе «Руководство по администрированию файловых систем ZFS Solaris».

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

zpool

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

# zpool create pool mirror sdb sdc

Когда дублирование информации пользователя не требуется, носители информации можно объединить, сложив их ёмкости и увеличив скорость доступа:

# zpool create pool sdb sdc

В вышеприведённых примерах pool — произвольное имя создаваемого информационного поля. sdb и sdc — сокращения от путей /dev/sdb и /dev/sdc. Заметим, что в таком случае на каждом устройстве будут созданы GPT разметка и разделы:

Устр-во          Start   Конец Size Тип
/dev/sdc1         2048     31487999  15G Solaris /usr & Apple ZFS
/dev/sdc9     31488000     31504383   8M Solaris reserved 1

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

Если поле создано на переносном накопителе, для безопасного отключения служит команда:

# zpool export pool

а для подключения:

# zpool import pool

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

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

Запуск задачи очистки от повреждений производится командой:

# zpool scrub pool 

а проверка состояния:

# zpool status

Произведённые операции сохраняются в журнале, для просмотра которого служит:

# zpool history

zfs

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

# zfs list

В таком виде уже возможно использовать ZFS — как обычную ФС. Если желательно монтировать традиционно, командой mount и посредством /etc/fstab, то следует изменить соответствующее свойство таким образом:

# zfs set mountpoint=legacy pool

Для просмотра свойств предназначен вариант get, например, их перечень можно получить так:

# zfs get all

Ряд свойств должен быть знаком тем, кто редактировал файл /etc/fstab. ZFS хранит их поближе к характеризуемым структурам, что бы «инструкция по использованию» была под рукой. Но это не мешает использовать и привычный подход.

Зачем нужна zfs, когда есть zpool?

Как правило, предпочтительно отделять данные пользователя в /home от системных. В ряде случаев требования к гибкости файловой иерархии повышены, а заранее предугадать количество разделов не представляется возможным. ZFS избавляет пользователя от вопросов «какие лучше выбрать размеры разделам?» и позволяет организовать в едином поле произвольное множество файловых систем, распределяя общий объём памяти по мере надобности, а при необходимости даёт возможность добавить новые физические носители.

В таких сценариях автоматически созданную ФС не используют непосредственно для хранения данных. Её рассматривают как родительскую: задают свойства, которые требуется унаследовать дочерним структурам, например:

# zfs set compression=lz4 pool
# zfs set acltype=posixacl pool
# zfs set xattr=xa pool

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

# zfs create pool/ROOT
# zfs create pool/ROOT/rosa-1
# zfs create -o mountpoint=/home pool/home

Как видно, свойства можно задавать непосредственно при создании ФС, а не только менять позже. Отличная от legacy точка монтирования /home приведёт к тому, что pool/home окажется доступен по соответствующему пути в случае импорта, или команды zfs mount -a. Однако, нужно учитывать тонкость: свойство overlay по умолчанию off — если что-либо по заданному пути уже смонтировано, то оверлей создан не будет.

Помимо pool/ROOT/rosa-1 можно создать pool/ROOT/rosa-2 и установить два варианта ОС. Копию можно создавать не только привычным методом, но и используя механизм мгновенных снимков состояния zfs snapshot и клонирования zfs clone. С учётом таких сценариев, а так же возможности chroot, вместо mountpoint=/ удобнее выбрать legacy (и если читатель выполнил пример из предыдущего раздела, то оно таким и унаследовано от pool)

Запуск ОС Роса с ZFS

Осуществляется просто, если на диске создан отдельный раздел /boot для grub2 и ядер ОС. В таком случае в grub.cfg в качестве параметра ядра root следует указать путь к корневому разделу, возможны различные варианты:

linux	/vmlinuz-4.4.7-nrj-laptop-1rosa-x86_64 root=ZFS=pool/ROOT/rosa-1 ro 

linux	/vmlinuz-4.4.7-nrj-laptop-1rosa-x86_64 root=zfs: ro  zfs=pool/ROOT/rosa-1

С этой задачей справляется update-grub2 из официальных репозиториев, но в некоторых случаях требуется недавняя beta версия. Так же желательно установить и соответствующее свойство:

# zpool set bootfs=pool/ROOT/rosa-1