ZFS и Ubuntu 13.10

Алексей Федорчук
Ubuntu’вы страсти, 20.11.2013

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

Нельзя было исключить того, что это было связано с исходной «чужеродностью» пула ZFS — всё-таки с момента его создания сменилась не одна версия авторского ZFS on Linux, причём текущая рассматривается её разработчиками как пригодная к промышленному использованию. И потому при новой инсталляции Ubuntu я решил проделать всю работу по созданию zpool‘а и datasets на нём с нуля.

От идеи размещения на ZFS корня файловой иерархии по неоднократно описанной методике (например, здесь и здесь), я отказался изначально. Во-первых, процесс этот весьма затратный по времени и, как показали мои предыдущие эксперименты на виртуальной машине, результат его не всегда предсказуем — в частности, он зависит от версии и дистрибутива, и ZFS on Linux. Во-вторых, размещение корневой файловой системы на ZFS всё равно требует отдельного раздела под /boot с одной из традиционных файловых систем (впрочем, практически выбор сводится к одному из вариантов, ext2fs или ext4fs), что во многом лишает смысла всю затею. В-третьих же и главных, на пользовательском десктопе в качестве корневой ZFS не выказывает своих основных преимуществ, таких, как простота управления дейтасетами и их «безразмерность».

А вот в качестве хранилища пользовательских данных применение ZFS более чем оправдано. Как имеет смысл и отделение их от домашнего каталога пользователя — я давно уже не храню в /home/username ничего, кроме dot-файлов, почему и не вижу смысла выносить /home на отдельный раздел, о чём вскользь упоминалось раньше. Вместо этого у меня предусмотрен раздел с точкой монтирования /home/data, в котором размещены подкаталоги для текущих проектов и других постоянно востребованных и часто изменяемых данных. Вот под него-то и имеет смысл задействовать ZFS.

ZFS с нуля

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

$ sudo -i

Затем следовало установить пакеты, обеспечивающие поддержку ZFS on Linux. Они расположены в одном из PPA-репозиториев, который я и подключил:

# add-apt-repository ppa:zfs-native/daily

Я воспользовался так называемой «ежедневной» сборкой, которая казалась мне, в свете предшествующих шероховатостей, более актуальной. И, как оказалось впоследствии, оказался не прав: именно ею и были обусловлены описанные ранее проблемы. Так что здесь надо было использовать репозиторий stable.

После чего, обновив кэш пакетов

# apt-get update

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

# apt-get install ubuntu-zfs

Напомню, что входящие пакеты с модулями ядра для поддержки ZFS on Linux (zfs-linux и spl-linux) собраны не статически, а с использованием так называемого механизма dkms (Dynamic Kernel Module Support), то есть каждый раз компилируются для текущей версии ядра. И потому процесс их установки может быть достаточно долгим, ибо требует предварительной установки всего сборочного инструментария (gcc, binutils и так далее), а затем и собственно компиляции модулей.

Теперь осталось только включить поддержку ZFS в системе:

# modprobe zfs

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

# lsmod | grep zfs
zfs                  1144227  4
zunicode              331251  1 zfs
zavl                   15010  1 zfs
zcommon                47181  1 zfs
znvpair                88812  2 zfs,zcommon
spl                   168728  5 zfs,zavl,zunicode,zcommon,znvpair

Или вот так:

# dmesg | grep -i zfs
[    2.411326] ZFS: Loaded module v0.6.2-1~saucy, ZFS pool version 5000, ZFS filesystem version 5

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

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

# mkdir /home/data

За этим последовало создание пула:

# zpool create -o ashift=12 -m /home/data data /dev/sda3 /dev/sdb3

Как можно видеть из команды, я создал простой пул, без избыточности — в данной ситуации смысла в ней нет. И действительно использовал имена «верхнего уровня», а не рекомендуемые проектом ZFS on Linux для таких случаев имена по схеме by-id: переключать диски на другие разъёмы не предполагается. Да и всё равно оно вызвало бы развал системы из-за программных RAID’ов.

А поскольку оба моих SSD имели, судя по выводу fdisk, размер физического блока 512 байт, то значением опции -o ashift=12 узакзал это явным образом — хотя в данном случае она не обязательна (в отличие от носителей с размером блока 4K — для них её указывать очень советуют).

Проверил результат командой

# zpool status data

которая выдала мне такое:

  pool: data
 state: ONLINE
  scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	data        ONLINE       0     0     0
	  sda3      ONLINE       0     0     0
	  sdb3      ONLINE       0     0     0

errors: No known data errors

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

# zfs create data/proj
# zfs create data/media
# zfs create data/other

Командой

# sudo zfs list

убедился в правильности своих действий:

NAME         USED  AVAIL  REFER  MOUNTPOINT
data        22,3G   170G    33K  /home/data
data/media  3,48G   170G  3,48G  /home/data/media
data/other  7,55G   170G  7,55G  /home/data/other
data/proj   11,3G   170G  11,3G  /home/data/proj

И перешёл к установке свойств файловых систем. Первым делом отменил изменение atime и использование xattr, ибо мне не нужно:

# zfs set atime=off data
# zfs set xattr=off data

Поскольку дейтасет /home/data/media, содержащий мультимедийные файлы, имеет тенденцию к безграничному росту, резервирую место под два остальных, «производственных» — побольше для проектов:

# zfs set reservation=10G /home/proj

и поменьше для остального:

# zfs set reservation=1G /home/other

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

# zfs set copies=2 /home/proj

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

# zfs set checksum=off /home/media

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

# chown -R alv:alv /home/data

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

ZFS и проблемы

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

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

# zpool export data
# zpool import data

Обращаю внимание на отсутствие опции -f в последнем случае, о необходимости которой столько говорилось ранее. Я про неё не забыл, а опустил сознательно, в экспериментальных целях…

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

Изучение странички Launchpad’а, посвящённой zfs-native, показало, что дело тут в пакете mountall, точнее, в его версии: последняя из них, 2.52, как раз и содержала выявленную ошибку (кстати, в багзилле проекта ZFS on Linux соответствующий баг зафиксирован). И хотя в репозитории ppa:zfs-native/daily она была помечена как удалённая и заменена на предыдущую, но почему-то устанавливалась именно она.

Короче говоря, проблема решилась заменой ppa:zfs-native/daily на ppa:zfs-native/stable, обновлением кэша и переустановкой пакета — правда, у меня она произошла в рамках плановой процедуры

$ sudo apt-get upgrade

С тех пор никаких проблем с монтированием ZFS более не возникало.

Добавить комментарий