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

https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS

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

0. Подготовка сервера

Первое, что пропущено в инструкции и никак не рассматривается, это то что ZFS не очень хорошо работает с аппаратными RAID массивами, в частности это связано с Write cache, что понятно: файловая система ZFS — журналируемая и требует полного контроля над операциями записи. Так же при использовании готового аппаратного RAID массива теряются возможности ZFS в части Cache, Spare и прочего. Поэтому, все диски требуется перевести в HBA Mode, а при невозможности оного — сделать для каждого диска сделать отдельный RAID и отключить Write Cache контроллера.

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

1. Подготовка среды установки

1.1. LiveCD

Как было сказано ранее, к сожалению, еще нет готового установщика Ubuntu с использованием root on ZFS, поэтому установка осуществляется с помощью LiveCD диска:

Качаем отсюда: http://releases.ubuntu.com/18.04/ubuntu-18.04.1-desktop-amd64.iso

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

Загружаемся с LiveCD, выбираем Try Ubuntu и открываем терминал (Ctrl+Alt+T).

1.2. Обновляем и устанавливаем репозитории

sudo apt-add-repository universe
sudo apt update

Вот тут нас ждет первый облом если сетевые настройки сервера не определяются DHCP. Обновление репозиториев работать не будет, поэтому настроим сеть.

Смотрим сетевые интерфейсы и находим тот через который будем соединятся:

sudo ip a

Настраиваем сетевой интерфейс:

sudo echo "auto {{ NAME }}" >> /etc/network/interfaces
sudo echo "iface {{ NAME }} inet static" >> /etc/network/interfaces
sudo echo "	address {{ IP }}" >> /etc/network/interfaces
sudo echo "	netmask {{ NETMASK }}" >> /etc/network/interfaces
sudo echo "	gateway {{ GATEWAY }}" >> /etc/network/interfaces
sudo service networking restart

И DNS resolver:

sudo echo 'nameserver 8.8.8.8' >> /etc/resolv.conf

Обновляем репозитории:

sudo apt update

1.3. SSH сервер (опционально)

Для удобства установки можно поднять OpenSSH сервер и все дальнейшие операции производить через SSH клиент

Задаем пароль для пользователя ubuntu:

passwd

Это важно! Так как иначе доступ по ssh будет осуществляться без пароля с правами sudo. При этом нельзя устанавливать простой пароль.

Устанавливаем и запускаем OpenSSH:

sudo apt install openssh-server
sudo service ssh start

И в терминале рабочей станции:

ssh ubuntu@{{ ip server }}

1.4. Становимся root

sudo -s

1.5. Устанавливаем поддержку ZFS в среде LiveCD

apt install --yes debootstrap gdisk zfs-initramfs

2. Разметка и форматирование жестких дисков

2.0. Определяем дисковые массивы

В основной инструкции отсутствует важный момент о том — каким образом определять дисковые массивы.

Обычно на серверах количество дисков такое:

• 2 диска;
• 4 диска;
• много дисков;

1 диск не рассматриваем ибо это вообще аномалия.

2.0.1. 2 диска

Тут все просто, один массив MIRROR (RAID1). Если есть еще один третий диск, то можно его поставить в горячий резерв (SPARE) либо собрать RAIDZ массив (RAID5). Но 3 диска в сервере, очень большая редкость.

2.0.2. 4 диска

Если все диски у нас одинаковы, вариантов тут всего три (четвертый RAID0 я в принципе не рассматриваю):

• MIRROR + MIRROR — аналог RAID10 точнее RAID01, так как в ZFS это mirror + mirror. 50% доступного дискового пространства;
• RAIDZ — аналог RAID5. 75% доступного дискового пространства;
• RAIDZ2 — аналог RAID6. 50% доступного дискового пространства;

На практике я использую MIRROR + MIRROR массив, при этом очевидно, что наиболее выгоден RAIDZ массив, так как предоставляет большее дисковое пространство, но есть нюансы

В части отказоустойчивости массивы располагаются в таком порядке (от лучшего к худшему):

• RAIDZ2 — могут быть утеряны два диска, без потери данных;
• MIRROR + MIRROR — может быть утерян один диск без потери данных, и с 66% вероятностью может быть потерян второй диск без потери данных;
• RAIDZ — может быть потерян только один диск без потери данных;

В части скорости работы массивы располагаются в таком порядке:

• MIRROR + MIRROR — как в части записи так и в части чтения;
• RAIDZ — в части записи медленнее, так как кроме записи требуется рассчитать контрольную сумму;
• RAIDZ2 — в части записи еще медленней так как требует расчета более сложных контрольных сумм;

В части скорости работы массива при деградации одного диска:

• MIRROR + MIRROR — при выпадении одного диска по сути теряется только параллельное чтение с одного зеркала, второе зеркало работает без деградации производительности;
• RAIDZ2 — деградация по снижению производительности выше так как требует обратного перерасчета блока из контрольной суммы для 1/4 данных + поиск блока;
• RAIDZ — деградация сильно больше, так как требует обратного перерасчета блока из контрольной суммы для 1/3 данных + поиск блока;

Сравнение характеристик субъективное, но достаточно отражает мой выбор как золотую середину.

При этом надо понимать, что “медленней” и “еще медленней” — это не в разы, а всего на 10-20 % в худшем случае, поэтому, если у вас не оптимизирована база или приложение для работы с дисками, то падение скорости вы в принципе не заметите. Фактор скорости записи следует учитывать только тогда, когда вам действительно это нужно.

2.0.2. Много дисков

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

• 2 SSD диска — делаем зеркало и как основной загрузочный массив с операционной системой и ZFS кешом для второго дискового массива;
• Остальное забиваем SATA или SAS дисками и без разметки собираем ZFS дисковый массив;

Это равно же относится и к 4-х дисковым серверам если мы хотим получить достаточно универсальную платформу;

В случае если диски все одинаковы, и выделить два диска под отдельный массив бессмысленно (например 6 дисков по 8 Tb), то можно сделать загрузочными диски первой группы массива. То есть если вы собираетесь делать массив как: MIRROR + MIRROR + MIRROR или RAIDZ + RAIDZ, то загрузочный сектор размечаем только для первой группы. В принципе, можно разметить вообще только один диск даже для MIRROR и RAIDZ, а остальное подставить в “сыром” виде, ZFS сделает массив по меньшему элементу сам, но в таком случае, при сбое первого диска, вы теряете единственный загрузочный диск, поэтому не стоит так делать.

Важно понимать, что в файловой системе ZFS — stripe это не совсем RAID0, и работает он немного по-другому и не требует одинаковых размеров дисков, поэтому выделение небольшого пространства под загрузочный сектор погоды особо не сделает, главное указать в BIOS правильный диск с которого загружаться.

2.1. Подготовка к разметке и очистка диска

Для разметки диска используется пакет mdadm, ставим его:

apt install --yes mdadm

Смотрим, какие диски у нас в наличии:

lsblk

И чистим их:

sgdisk --zap-all /dev/{{ disk name }}

2.2. Разметка диска

Собственно, загрузочный раздел:

sgdisk -a1 -n1:34:2047 -t1:EF02 /dev/{{ disk name }}

Основной раздел.

Вот тут могут быть вариации: если у вам требуется выделить дополнительный раздел SSD дисков, например, для ZFS Cache или для Aerospike, то основной раздел делаете ограниченного объема:

sgdisk -n2:0:+100GB -t2:BF01 /dev/{{ disk name }}
sgdisk -n3:0:0 -t2:BF01 /dev/{{ disk name }}

Если же используем все пространство, то просто создаем раздел на все оставшееся место:

sgdisk -n2:0:0 -t2:BF01 /dev/{{ disk name }}

Не забываем проверить, как что получилось:

lsblk

NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0  1.8T  0 disk 
+-sda1   8:1    0 1007K  0 part 
L-sda2   8:2    0  1.8T  0 part 
sdb      8:16   0  1.8T  0 disk 
+-sdb1   8:17   0 1007K  0 part 
L-sdb2   8:18   0  1.8T  0 part 
...

2.3. Создание ZFS массива

zpool create                	    -o ashift=12            	    -O atime=off            	    -O canmount=off         	    -O compression=lz4      	    -O checksum=fletcher4   	    -O normalization=formD  	    -m legacy               	    -R /mnt                         -f                      	  tank                      	    mirror                  	      /dev/{{ disk a part 2}}         /dev/{{ disk b part 2}}

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

Далее, по порядку:

• ashift=12 — использовать размер блока в 4К, в принципе я до сих пор не понимаю, почему зачастую в операционных системах размер блока по умолчанию 512 байт когда как таких дисков уже практически нет;
• atime=off — отключить одновление даты доступа к файлам, всегда выключаю так как эта информация мне никогда особо не требовалась и нагружать лишний раз ядро для этого не требуется;
• canmount=off — запретить возможность монтирования корневого раздела;
• compression=lz4 — включить компрессию данных алгоритмом LZ4. Этот параметр рекомендуется включать не только для экономии дискового пространства, но и для снижения количества операций ввода-вывода. При этом для этого аглоритма сжатия крайне низкая утилизация CPU;
• checksum=fletcher4 — алгоритм контрольных сумм по-умолчанию и так fletcher4 просто лишний раз уточнить стоит;
• normalization=formD — используется для улучшения работы с UTF-8, по факту ограничивая возможность использования имен файлов не UTF-8. Тут уж каждый рашает сам, мы в своей работе всегда используем только кодировку UTF-8;
• xattr=sa — Ускорение работы с расширенными атрибутами. Я не использую эту опцию по причине того, что при использовании этой опции отключается совместимость с другими реализациями OpenZFS (например: FreeBSD). А совместимость с Windows и прочим, нам мне нужна. Тем более что эту опцию можно включить на конечном разделе;
• -m legacy — точка монтирования в никуда, и монтировать корневой раздел не надо;
• -R /mnt — временный префикс монтирования разделов для установки ядра;
• -f — форсировать создание массива. Если до этого на дисках был собран ZFS массив, то команда create не сработает, мало ли, может вы ошиблись и хотите важные данные перетереть;

Имя корневого системного дискового массива я по привычке указываю как tank, хотя в данный момент в среде Linux предпочитают использовать имя rpool (root pool). В своей практике я вообще использую такое именование массивов:

• tank — основной системный массив;
• store — дополнительный массив с большими дисками для хранения данных;
• cache — дополнительный массив из SSD дисков, если основной раздел находится не на них;

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

3. Установка системы

3.1. и 3.2. Создание корневой файловой системы

Я специально объединил пункты 3.1. и 3.2. так как считаю, что указание корневого раздела на третьем уровне абсолютно излишне. Вот правда, за несколько лет работы с ZFS мне ни разу не потребовалось производить какие-нибудь манипуляции с корневым разделом. Тем более, есть же снимки, с помощью которых можно делать контрольные точки. Поэтому корневым разделом у меня является tank/root:

zfs create -o mountpoint=/ tank/root

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

zpool set bootfs=tank/root tank

3.3. Создание дополнительных разделов

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

Совсем уж эпично выглядит выделение отдельного радела для /var/games. Мне не жалко, но это явно перебор.

То, что в ZFS разделы создаются просто и поддерживают иерархию, это не значит что следует отказываться от классических директорий. Простой пример: у меня однажды на группе серверов было более 4K ZFS разделов, так было нужно, но перезагрузка сервера замедлялась на несколько минут из-за монтирование этих разделов.

Начнем с чистого листа.

Есть статичные и динамические файловые разделы.

К статичным файловым разделам относятся разделы с программами и их настройками, они наполняются один раз и в процессе работы не изменяются. При этом ранее статичные разделы подразделялись на системные и пользовательские (/usr), но в данный момент в операционных системах семейства Linux они перемешались и разделять их смысла нет никакого, да и не получится.

К динамичным файловым разделам относятся разделы в которых хранятся:

• Временные данные — eq.: tmp, swap;
• Журналы работы — eq.: var/log;
• Пользовательские данные — eq.: home;
• Данные — eq.: var/db и как повезет;
• Прочие результаты работы программ в виде файлов;

В семействах Linux к динамическим разделам относятся /tmp и /var, но это не точно, так как в /var/lib могут попасть, программы и библиотеки, в общем, все смешалось, но тем не менее…

Для начала требуется решить, создавать раздел /tmp на диске или же в памяти как tmpfs. Если создаем на диске, то тогда для него создаем отдельный раздел:

zfs create -o mountpoint=legacy tank/tmp

Опции com.sun:auto-snapshot=false setuid=off ну как бы погоды не сделают, не надо усложнять. А вот со SWAP сделаем позже в п.7.

Выделяем отдельно раздел var:

zfs create -o mountpoint=legacy tank/var

И пользовательские разделы:

zfs create -o mountpoint=/home tank/home
zfs create -o mountpoint=legacy tank/home/root

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

точка монтирования tank/home/root указана как legacy, а не как /root. Это правильно, та как монтирование этого раздела осуществляется в п.4.11

Теперь требуется временно примонтировать наши динамические разделы в /mnt:

cd /mnt/
mkdir var tmp root
mount -t zfs tank/var /mnt/var/
mount -t zfs tank/tmp /mnt/tmp/
mount -t zfs tank/home/root /mnt/root/

3.4 Устанавливаем ядро

В основной инструкции еще пара ненужных команд, не обращаем внимание, видимо артефакты экспериментов:

debootstrap bionic /mnt

В итоге должны получить примерно такую картину:

zfs list

NAME             USED  AVAIL  REFER  MOUNTPOINT
tank             213M  1.76T    96K  legacy
tank/home        208K  1.76T    96K  /mnt/home
tank/home/root   112K  1.76T   112K  legacy
tank/root        147M  1.76T   147M  /mnt
tank/tmp          96K  1.76T    96K  legacy
tank/var        64.6M  1.76T  64.6M  legacy

Размер пустого раздела 96К соответственно у нас пустым остался только tank/tmp, а в остальные при установке ядра была произведена запись, значит монтирование разделов было осуществлено правильно.

4. Конфигурация системы

4.1. Настраиваем hosts и hostname

echo HOSTNAME > /mnt/etc/hostname
echo “127.0.0.1 localhost” > /mnt/etc/hosts
echo “127.0.0.1 HOSTNAME” >> /mnt/etc/hosts

4.2. Настраиваем сетевой интерфейс

Таки да, у нас тут уже netplan:

nano /mnt/etc/netplan/setup.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    eno2:
      dhcp4: no
      dhcp6: no
      addresses: [ {{ IP }}/{{ netmask }}, ]
      gateway4: {{ gateway IP }}
      nameservers:
        addresses: [8.8.8.8]

4.3. Настраиваем apt репозитории

nano /mnt/etc/apt/sources.list

deb http://archive.ubuntu.com/ubuntu/ bionic main restricted universe
deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted universe
deb http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted universe

src — не нужны в основном

4.4. Монтируем виртуальные файловые разделы LiveCD и «заходим» в новую систему

mount --rbind /dev  /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys  /mnt/sys
chroot /mnt /bin/bash --login

требуется использовать именно —rbind, а не —bind

Мы уже в новой системе…

4.5. Настраиваем базовую среду

ln -s /proc/self/mounts /etc/mtab
chmod 1777 /tmp
apt update

Локаль и время:

dpkg-reconfigure locales

  * en_US.UTF-8
  * ru_RU.UTF-8

dpkg-reconfigure tzdata

И дополнительные редакторы, кому что нравится:

apt install --yes vim nano

4.6. Устанавливаем поддержку ZFS

apt install --yes --no-install-recommends linux-image-generic
apt install --yes zfs-initramfs

4.8. Устанавливаем загрузчик

Как сказано ранее, я использую устаревший MBR:

apt install --yes grub-pc

Во время установки загрузчика требуется выбрать все наши диски которые мы определили как загрузочные, при этом установщик ругнется на все остальные диски кроме первого, соглашаемся и делаем п.5 (непонятно почему остальное оставили на потом):

4.8.1. (5.1) Проверяем что корневая файловая система распознается:

grub-probe /

zfs

4.8.2. (5.2) Обновляем initrd

update-initramfs -u -k al

4.8.3. (5.3) Упрощаем отладку GRUB

vi /etc/default/grub

...
GRUB_CMDLINE_LINUX_DEFAULT=""
GRUB_CMDLINE_LINUX="console"
...

4.8.4. (5.4.) Обновляем конфигурацию загрузчика

update-grub

4.8.5. (5.5.) Устанавливаем загрузчик на каждый диск которые разметили как загрузочные

grub-install /dev/sda
grub-install /dev/sdb
...

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

4.8.6. (5.6.) Проверяем, что модуль ZFS установлен

ls /boot/grub/*/zfs.mod

/boot/grub/i386-pc/zfs.mod

4.10. Задаем пароль пользователя root (сложный!)

passwd

И да, поставим сразу openssh, иначе получим сюрприз после рестарта, если работаем удаленно:

apt install --yes openssh-server

Не забываем при этом поправить конфигурацию sshd:

vi /etc/ssh/sshd_config

...
PermitRootLogin yes
...
PasswordAuthentication yes
...

4.11. Исправление монтирования файловых систем

Вот добрались до самого интересного. Дело в том, что монтирование ZFS разделов происходит после старта некоторых демонов (ZFS_INITRD_ADDITIONAL_DATASETS в /etc/default/zfs мы тоже шатали, но безуспешно), которые, в свою очередь самостоятельно создают некоторую структуру в /var начинают заполнять системные журналы. Когда же настает время монтирования ZFS разделов выясняется что точки монтирования не пустые и смонтировать ничего не получается, данные рассыпаются, все плохо. Поэтому требуется указать точки монтирования в /etc/fstab так как systemd в первую очередь ориентируется на них при обращении к папке:

vi /etc/fstab

tank/var        /var   zfs  noatime,nodev 0 0
tank/tmp        /tmp   zfs  noatime,nodev 0 0
tank/home/root  /root  zfs  noatime,nodev 0 0

Остальное до п.6. уже сделано

6. Первая перезагрузка

6.1. Делаем снимок корневого раздела

zfs snapshot tank/root@setup

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

6.2. Выходим из chroot

exit

6.3. Отмонтируем разделы LiveCD и экспортируем ZFS массив

cd
mount | grep -v zfs | tac | awk '/\/mnt/ {print $3}' | xargs -i{} umount -lf {}
umount /mnt/root
umount /mnt/var
umount /mnt/tmp
zpool export tank

Экспорт дискового массива требуется для очистки кеша zfs

6.4 Перезагрузка

Перезагрузку лучше делать в терминале LiveCD, так как если вы работает через ssh клиент, перезагрузка через него может привести к «зависанию» сервера.

reboot

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

6.5. Ждем перезагрузки и заходим как root

6.6. Создаем учетную запись своего пользователя

zfs create tank/home/{{ LOGIN }}
useradd -u {{ UID }} -G adm,sudo -d /home/{{ LOGIN }}/ -s /bin/bash {{ LOGIN }}
cp -a /etc/skel/.[!.]* /home/{{ LOGIN }}
chown -R {{ LOGIN }}:{{ LOGIN }} /home/{{ LOGIN }}

Добавляем публичный ssh ключ пользователю и задаем ему пароль:

su - {{ LOGIN }}
mkdir .ssh
chmod 0700 .ssh
vi .ssh/authorized_keys
exit
passwd {{ LOGIN }}

В OpenSSH убираем возможность авторизоваться root и парольную авторизацию:

vi /etc/ssh/sshd_config

...
PermitRootLogin no
...
PubkeyAuthentication yes
...
PasswordAuthentication no
...

service ssh restart

6.7. 6.8. Уже не требуется

7. Настройка swap

7.1. Создаем раздел ZFS

zfs create     -V 32G     -b $(getconf PAGESIZE)     -o compression=zle     -o logbias=throughput     -o sync=always     -o primarycache=metadata     -o secondarycache=none   tank/swap

• -V 32G — Размер нашего SWAP, можно определить тот который требуется реально;
• -b $(getconf PAGESIZE) — размер блока (4K c ashift=12);
• compression=zle — выбираем минимальный по ресурсоёмкости алгоритм сжатия, по сути так как размер блока у нас 4К, то сжатия как таковое не даст утилизации по вводу-выводу, но при этом можно будет сэкономить на нулевых блоках;
• logbias=throughput — установка пропускной способности для оптимизации синхронных операций;
• sync=always — всегда синхронизировать запись. Это несколько снижает производительность, но полностью гарантирует достоверность данных;
• primarycache=metadata — кешировать только метаданные, так как из swap не будет производится множественное чтение одного и того же блока;
• secondarycache=none — вторичный кеш вообще отключить по причинам указанным выше;

7.2. Настраиваем раздел подкачки

mkswap -f /dev/zvol/tank/swap
echo /dev/zvol/tank/swap none swap defaults 0 0 >> /etc/fstab
echo RESUME=none > /etc/initramfs-tools/conf.d/resume

7.3. Включаем swap

swapon -av

Далее по инструкции мало чего интересного, так как сильно зависит от предпочтений конкретных администраторов и задач сервера в целом, кроме одного момента, а именно: “Аварийная загрузка”

И не забываем поставить FireWall

R. Аварийная загрузка

Выполняем подготовку среды установки (п.1.)

Во время подготовки происходит импорт ZFS массива, поэтому требуется его переимпортировать, но с правильной точкой монтирования:

zpool export -a
zpool import -N -R /mnt tank
zfs mount -a

Тут, конечно, забыли в исходной инструкции про то, что у нас некоторые разделы монтируются через fstab, но исправим эту ошибку:

mount -t zfs tank/var /mnt/var/
mount -t zfs tank/tmp /mnt/tmp/
mount -t zfs tank/home/root /mnt/root/

Далее, если это требуется, можно сделать chroot как в п.4.4., но не забыть в последствии размонтировать все как в п. 6.3.

D. Динамические разделы

В пункте 3.3. мы рассмотрели вопросы дополнительных разделов и упростили работу с ними относительно исходной инструкции. Это обусловлено в первую очередь тем, что у меня другая практика использования динамических разделов: так, журналы приложений я сохраняю в разделе /spool, а данные храню в разделе /data. Причем при наличии второго дискового массива ZFS эти разделы создаются именно там.

Резюме

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