Алексей Федорчук
Включение поддержки ZFS было одним из первых моих деяний после установки Salix’а. Ибо без этого дистрибутив для меня практического смысла не имеет — все мои рабочие данные расположены на zpool
‘е, который должен быть доступен для всех установленных систем. Иначе они годились бы только «на посмотреть».
Устанавливая Salix, я был уверен в успехе решения этой задачи, поскольку из сетевых материалов знал, что в Slackware поддержка ZFS on Linux в принципе существует, а Slackware и Salix — братья навек. Однако всё оказалось гораздо проще, и необходимые пакеты нашлись, не выходя из границ родных репозиториев.
Как и следовало ожидать, поиск по ключевому слову zfs
среди бинарных пакетов результата не дал. Но зато среди слакбилдов легко обнаружился и zfs-on-linux.SlackBuild
, и spl-solaris.SlackBuild
. Кроме них, требуется также пакет kernel-headers
(был установлен по умолчанию при начальной инсталляции) и исходники ядра той же версии, которая используется в системе. Так что для начала я определил таковую командой
$ uname -a Linux salix 3.10.17 #2 SMP ...
После чего присвоил себе перманентные права администратора (далее они будут нужны постоянно)
$ sudo -i
и установил соответствующий пакет:
# slapt-get --i kernel-source-3.10.17-noarch-2
Обращаю внимание, что требуется именно uname -a
, потому что uname -r
не даёт номера сборки, который не менее важен.
Далее последовательно были собраны требуемые слакбилды — сначала:
# slapt-src -i spl-solaris
а затем
# slapt-src -i zfs-on-linux
Делать это нужно именно в указанном порядке, иначе последует сообщение об ошибке.
Следующий шаг — подключение соответствующих модулей
# sudo modprobe zfs
и проверка результатов этого деяния:
# lsmod |grep zfs zfs 997378 5 zunicode 320867 1 zfs zavl 4875 1 zfs zcommon 32148 1 zfs znvpair 49518 2 zfs,zcommon spl 123549 5 zfs,zavl,zunicode,zcommon,znvpair
Перед импортом существующего пула я не забыл создать каталог — точку монтирования его datasets
# mkdir /home/data
и назначить для него «правильного хозяина»:
# chown -R alv:users data
Обращаю внимание: во всех используемых мной Linux-системах первый пользователь, то есть я, любимый, имеет UID 1000. Если в системах моего читателя это не так (например, есть дистрибутивы, присваивающие первому юзеру UID 500, возможно, существуют и другие варианты), то «право принадлежности» надо указывать в численном выражении. Что же до принадлежности группе и её GID, то в данном (моём) случае это рояля не играет. Если это важно для читателя — следует учесть и этот фактор.
Это с одной стороны. А с другой — есть подозрение, что при монтировании дейтасетов импортируемого пула все они автоматом получают те права принадлежности и доступа, которые были у них в исходной системе. Каюсь, вот уже за пару лет применения одних и тех же пулов в разных дистрибутивах я не то что прочитать — даже проверить это не удосужился.
Теперь — самый ответственный момент, импорт существующего пула:
# zpool import -f data
Проверка показывает, что он прошёл успешно:
# zpool status 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
Да ещё и все дейтасеты, входящие в пул, сами собой смонтировалсь куда надо:
# zfs mount data /home/data data/media /home/data/media data/other /home/data/other data/proj /home/data/proj data/vbox /home/data/vbox
Так что мой пул данных полностью пригоден к работе…
… увы, до перезагрузки системы. После которой ни малейших следов смонтированных файловых систем zpool
‘а мы не обнаруживаем. Хотя сам пул задействован, и команда zpool status
возвращает правильный ответ, такой же, как раньше. Согласно ZFS on Linux FAQ, это ситуация достаточно обычная (в частности, с ней же я сталкивался в тестовых вариантах Ubuntu Trusty). И тот же документ (в том числе и в русском переводе) предлагает в каждом дистрибутиве, не входящем в его «белый список» (а Slackware в него не входит) решать её силами рук самих утопающих.
Будучи одним из представителей последних, я, конечно, легко решил её командой
$ sudo zfs mount -a
после которой все файловые системы в /home/data
оказываются на своих местах. Однако это не дело — заниматься таким безобразием каждый раз после рестарта системы.
Процесс следует автоматизировать. Как? Теоретически рассуждая, разными способами. Я для начала избрал самый грубый, но простой, вспомнив о палочке-выручалочке каждого нерадивого слакварщика — файле /etc/rc.d/rc.local
, в который можно запихать всё невпихуемое в другие места. По умолчанию он пуст, но я это быстро исправил, вписав туда строку
zfs mount -a
обеспечивающую монтирование всех файловых систем подключённого пула ZFS при старте системы. А для симметрии добавил в /etc/rc.d/rc.local_shutdown
строку
zfs unmount -a
выполняющую обратную процедуру при выходе.
После этого проблем с доступом к файловым системам ZFS больше не наблюдалось. Правда, как легко догадается читатель, но обновления ядра — благо, автоматически оно обновляться не будет, так как входит в состав исключений. Однако если необходимость в пересборке или апгрейде ядра всё-таки возникнет — придётся также пересобрать модули zfs-on-linux
и spl-solaris
, сами собой они не соберутся.