Алексей Федорчук - Linux Mint и его Cinnamon. Очерки применителя
Для обеспечения монтирования файловых систем ZFS при рестарте машины не требуется и никаких записей в файле /etc/fstab: это также происходит само собой, совершенно нечувствительно для пользователя. Правда, если для файловой системы ZFS определить свойство mountpoint=legacy, то с ней можно управляться и традиционным способом.
Как и для обычного каталога, объём каждой файловой системы ничем не лимитирован, и в момент создания для любой из них потенциально доступно всё пространство пула, которое равномерно уменьшается по мере разрастания файловых систем. На данный момент в моей системе это выглядит так.
Казалось бы, для тех же целей можно ограничиться обычными каталогами. Однако в наборах данных ZFS мы имеем дело с полноценными файловыми системами, для которых могут быть установлены индивидуальные свойства, аналогичные опциям монтирования файловых систем традиционных. Чем мы сейчас и займёмся.
Файловые системы: устанавливаем свойства
При создании файловая система ZFS получает по умолчанию определённый набор свойств, во многом сходный с атрибутами традиционных файловых систем, определяемыми опциями их монтирования. Полный их список можно получить командой
# zfs get all fs_name
Свойств этих очень много, однако далеко не все они представляют для нас интерес. Важно только помнить, что любое из свойств каждой файловой системы можно поменять с помощью субкоманды set и её параметра вида свойство=значение. Причём изменение свойств для материнской системы рекурсивно распространяется на все дочерние. Однако для любой последней свойства можно изменить в индивидуальном порядке. Что я сейчас и проиллюстрирую на примерах.
Так, абсолютно лишним представляется свойство atime, то есть обновление времени последнего доступа к файлам. Оно, во-первых, снижает быстродействие, с другой — способствует износу SSD-накопителей (правда, нынче и то, и другое чисто символичны). Так что отключаем это свойство для всех файловых систем:
# zfs set atime=off tank/home
Аналогичным образом расправляемся и со свойством xattr:
# zfs set xattr=off tank/home
А вот дальше можно заняться и индивидуализацией. Как я уже говорил, в момент создания файловые системы ZFS «безразмерны». Если это не подходит, для них можно установить квоты. Однако я этого делать не буду — в моём случае это приводит к потере половины смысла ZFS. А вот зарезервировать место для критически важных каталогов, дабы его не отъела, скажем, мультимедиа, известная своей прожорливостью, будет не лишним. И потому я для файловых систем tank/home/proj и tank/home/alv устанавливаю свойство reservation. Для файловой системы проектов оно будет максимальным:
# zfs set reservation=10G tank/home/proj
Для остальных ограничусь более скромным гигабайтом резерва.
Далее, поскольку данные в файловой системе tank/home/proj для меня действительно важны, и шутить с ними я склонен даже гораздо меньше, чем с дамами, предпринимаю дополнительные меры по их сохранности путём удвоения числа копий (по умолчанию оно равно 1):
# zfs set copies=2 tank/home/proj
А для данных не столь важных — тех, что часто проще скачать заново, нежели отыскать на локальной машине, можно выполнить и обратную операцию — отказаться от подсчёта контрольных сумм:
# zfs set checksum=off tank/home/media
Для файловых систем, содержащих хорошо сжимаемые данные (например, для моего домашнего каталога, где лежат одни dot-файлы), можно включить компрессию:
# zfs set compression=on tank/home/alv
Я этого не делал: экономия места получается грошовая, а нагрузка на процессор и расход памяти, как говорят, очень приличные. Однако это свойство целесообразно включать в системах с огромными логами, если выделить под них файловую систему в пуле ZFS.
При желании для некоторых файловых систем (например, того же домашнего каталога) можно отключить такие свойства, как exec, setuid, devices — легко догадаться, что результат будет аналогичен указанию опций монтирования noexec, nosuid, nodev для традиционных файловых файловых систем. И, разумеется, для файловых систем, изменение которых нежелательно, можно придать свойство readonly.
Все необходимые свойства файловых систем желательно установить до их наполнения контентом, ибо многие из них (например, компрессия) обратной силы не имеют.
Перемонтирование
После создания файловых систем и задания всех необходимых их свойств наступает психологический момент для перемонтирования их по месту «постоянной прописки» — то есть в каталог /home. Что потребует некоторых подготовительных действий.
Поскольку предполагается, что все новообразованные файловые системы должны быть полностью доступны обычному пользователю (то есть мне, любимому), перво-наперво следует изменить атрибуты из принадлежности — ведь создавались они от имени администратора и принадлежат юзеру по имени root. Для чего даю команду: # chown -R alv:users /tank/home/*
Теперь нужно скопировать конфиги из каталога /home/alv в /tank/home/alv:
# cp -Rp /home/alv/.* /tank/home/alv/
не забыв про опцию -p для сохранения атрибутов.
Все предыдущие операции можно было выполнять, получив права администратора с помощью команды sudo. Причём где угодно — в текстовом виртуальном терминале или в терминальном окне Иксового сеанса. Теперь же потребуется переавторизоваться в «голой» консоли.
Монтирование файловых систем ZFS в каталог с любым содержимым невозможно, так что требуется очистить каталог /home от следов прежней жизнедеятельности пользователя таким образом:
# rm -Rf /home/alv
При хоть одном активном пользовательском процессе в ответ на это последует сообщение об ошибке. Так что, возможно, перед этим придётся убить все реликтовые процессы, запущенные в Иксах от имени пользователя. Сначала выявляем их командой
# ps aux | grep alv
обращая внимание на идентификаторы процессов (PID). А затем последовательно мочим их в сортире:
# kill -9 ####
Альтернативный способ — разрузка системы в recovery mode с выбором пункта меню root, что в Mint эквивалентно однопользовательскому режиму. В этом случае никаких пользовательских процессов не будет по определению, и перенос файлов из /home/username в /tank/home/username можно выполнить напрямую.
Выполнив все указанные действия, определяем для набора данных tank/home свойство mountpoint, что и осуществит перемонтирование:
# zfs set mountpoint=/home tank/home
Теперь остаётся только с помощью команды ls убедиться, что в /home появились новые подкаталоги с нужными атрибутами:
drwxr-xr-x 26 alv users 48 Sep 23 14:27 alv/ drwxr-xr-x 18 alv users 18 Sep 22 02:28 proj/ ...
А команда
# mount | grep /home
покажет нам новые точки монтирования файловых систем:
tank/home on /home type zfs (rw,noatime,noxattr) tank/home/alv on /home/alv type zfs (rw,noatime,noxattr) tank/home/proj on /home/proj type zfs (rw,noatime,noxattr) ...
На этом дело с подготовкой файловых систем ZFS к практической работе можно считать законченным: при перезагрузке машины все они будут благополучно смонтированы в автоматическом режиме.
Подключение пула ZFS, созданного в другой системе
Здесь речь пойдёт о том, как подключить к некоей Linux-системе (конкретно, Ubuntu) пул ZFS, ранее созданный в другой системе — теоретически это могут быть Solaris, FreeBSD или более иной дистрибутив Linux, для которого предусмотрена поддержка ZFS on Linux. Но практически я опробовал только последний вариант, о чём и расскажу.
Перво-наперво нужно перезагрузиться в ту систему, в которой создавался пул (в моём случае это была openSUSE), и экспортировать его командой:
# zpool export data
где data — имя пула с точкой монтирования /home/data.
Следующий шаг — вернуться в Ubuntu и создать в ней аналогичную точку монтирования для пула ZFS — в моём случае таким образом:
$ sudo mkdir /home/data
Дать ей атрибуты принадлежности обычному пользователю:
$ sudo chown -R alv:alv /home/data
И импортировать созданный в openSUSE пул ZFS:
$ sudo zpool import -f data
Не забыв об опции -f, предписывающей принудительной выполнение импорта. Без неё ответом на эту команду будет сообщение об ошибке.
Теперь в каталоге /home/data можно видеть те же самые файловые системы ZFS, которые были созданы в родителькой для пула системе, вместе со всеми размещёнными в них данными. С которыми можно начинать работать.
Сказанное справедливо, если идентификаторы пользователя в обеих системах совпадают — в моём случае это именно так. Однако в случае общем это совсем не обязательно — и тогда надо озаботиться каким-либо способом обеспечения совместного доступа к ним из разных систем. Впрочем, к ZFS, о которой мы сейчас разговариваем, это не имеет ни малейшего отношения.
Индивидуализация системы
Последний очерк посвящается апофеозу знакомства с дистрибутивом Mint и его Cinnamon — сборке индивидуализированной системы на его основе. Как сказал то ли один из премьер-министров Великобритании, то ли некий президент Франции (кому только это изречение ни приписывали?):
Тот, кто в (информационной) юности не мечтал собрать свой дистрибутив Linux'а, не имеет сердца. Тот, кто продолжает мечтать об этом в (информационной) зрелости — не имеет разума.
