В прошлом году потребовалось мне создать инструкцию по установке операционной системы Ubuntu 18.04. К слову, ничего сложного в установке Ubuntu нет, но есть нюанс: я хотел использовать файловую систему ZFS как базовую. С одной стороны, Ubuntu поддерживает ZFS на уровне ядра, но инсталятора под неё еще нет, но есть инструкция, да:
https://github.com/zfsonlinux/zfs/wiki/Ubuntu-18.04-Root-on-ZFS
Последовательность действий в этой инструкции в целом правильная, но некоторые моменты требуют корректировки. Так что далее не прямой перевод инструкции, а вольный с учетом исправлений, моего опыта работы с ZFS и прочего. Так же я не рассматриваю вопросы шифрования диска и используем MBR загрузчик. Мою же инструкцию по установке можно получить здесь.
0. Подготовка сервера
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.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
└─sda2 8:2 0 1.8T 0 part
sdb 8:16 0 1.8T 0 disk
├─sdb1 8:17 0 1007K 0 part
└─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 — это не замена каких либо классических вещей, а дополнительная возможность;
- Мою инструкцию установки можно получить здесь.
Автор: Сергей Томулевич