Алексей Федорчук
Ubuntu’вы страсти, 20.11.2013
Ранее говорилось о поддержке ZFS в Ubuntu 13.04, каковая не вызвала никаких проблем. В версии же 13.10 по этой части обнаружились некоторые шероховатости.
Нельзя было исключить того, что это было связано с исходной «чужеродностью» пула ZFS — всё-таки с момента его создания сменилась не одна версия , причём текущая рассматривается её разработчиками как пригодная к промышленному использованию. И потому при новой инсталляции 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 положения не исправил: файловые системы появлялись в должных точках монтирования, но только в текущем сеансе, опять пропадая после перезагрузки.
Изучение , показало, что дело тут в пакете mountall, точнее, в его версии: последняя из них, 2.52, как раз и содержала выявленную ошибку (кстати, в багзилле проекта ZFS on Linux соответствующий баг зафиксирован). И хотя в репозитории ppa:zfs-native/daily она была помечена как удалённая и заменена на предыдущую, но почему-то устанавливалась именно она.
Короче говоря, проблема решилась заменой ppa:zfs-native/daily на ppa:zfs-native/stable, обновлением кэша и переустановкой пакета — правда, у меня она произошла в рамках плановой процедуры
$ sudo apt-get upgrade
С тех пор никаких проблем с монтированием ZFS более не возникало.