• том [volume] – набор данных, эмулирующий физическое устройство, например, раздел подкачки.
Наборы данных пула должны носить уникальные имена такого вида:
pool_name/path/[dataset_name][@snapshot_name]
Пулы и наборы данных в именуются по правилам пространства имён ZFS, впрочем, довольно простым. Запрещёнными символами для всех являются символы подчёркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имён – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имён ZFS, разрешены.
А вот об именах физических устройств, включаемых в пул, следует сказать особо.
Модели именования устройств
В современном Linux’е использование для накопителей имён «верхнего уровня», имеющих вид /dev/sda, не является обязательным, а в некоторых случаях и просто нежелательно. Однако правила менеджера устройств udev позволяют определять и другие модели идентификации накопителей. В частности, штатными средствами дисковой разметки openSUSE предусмотрены варианты идентификации по:
• метке тома (/dev/disk/by-label);
• идентификатору диска (/dev/disk/by-id);
• пути к дисковому устройству (/dev/disk/by-path);
• универсальному уникальному идентификатору, Universally Unique IDentifier (/dev/disk/by-uuid).
А с полным списком вариантов идентификации блочных устройств можно ознакомиться, просмотрев имена подкаталогов в каталоге /dev/disk, их содержимое – это символические ссылки на имена «верхнего уровня».
С идентификацией по метке тома и по UUID, вероятно, знакомо большинство читателей. И к тому же в пространстве имён ZFS они не используются. А вот с идентификацией by-path и by-id нужно познакомиться поближе.
Модель именования by-path использует имена устройств, привязанные к их положению на шине PCI и включающие номер шины и канала на ней. Имя дискового устройства выглядит примерно так:
pci-0000:00:1f.2-scsi-0:0:0:0
Дисковые разделы маркируются добавлением к имени устройства суффикса part#. Модель именования by-path идентифицирует устройства вполне однозначно, и особенно эффективна при наличии более чем одного дискового контроллера. Однако сами имена и устройств, и разделов описываются довольно сложной для восприятия последовательностью. Да и в большинстве «десктопных» ситуаций модель эта избыточна.
Модель идентификации by-id представляет имена носителей информации в форме, наиболее доступной для человеческого понимания. Они образованы из названия интерфейса, имени производителя, номера модели, серийного номера устройства и, при необходимости, номера раздела, например:
ata-SanDisk_SDSSDX120GG25_120823400863-part1
Таким образом, все компоненты имени устройства в модели by-id определяются не условиями его подключения или какими-то правилам, а задаются производителем и жестко прошиты в «железе». И потому эта модель является наиболее однозначной для именования устройств. А также, что немаловажно, строится по понятной человеку логике. Не случайно именно она принята по умолчанию в инсталляторе openSUSE.
Какую из моделей именования устройств выбрать для данного пула – зависит от его назначения и масштабов. Имена «верхнего уровня» целесообразно применять для однодисковых пулов (особенно если в машине второго диска нет и не предвидится, как обычно бывает в ноутбуках). Они же, по причине простоты и удобопонятности, рекомендуются для экспериментальных и разрабатываемых пулов. И очень не рекомендуются – во всех остальных случаях, так как зависят от условий подключения накопителей.
Этого недостатка лишена модель by-id: как пишет Брайан, при её использовании «диски можно отключить, случайно смешать и подключить опять произвольным образом – и пул будет по-прежнему корректно работать». Как недостаток её рассматривается сложность конфигурирования больших пулов с избыточностью. И потому она рекомендуется для применения в «десктопных» и «квартирных» (типа семейного сервера) условиях.
Для больших (более 10 устройств) пулов из дисков, подключённых к нескольким контроллерам, рекомендуется идентификация by-path. Однако в наших целях она громоздка и избыточна.
Наконец, ZFS on Linux предлагает и собственную модель идентификации – /dev/disk/zpool, в котором именам by-path ставятся в соответствие уникальные и осмысленные «человекочитаемые» имена, даваемые пользователем. Модель эта рекомендуется для очень больших пулов, каковых на настольной машине ожидать трудно.
Так что дальше я буду использовать имена «верхнего уровня», говоря об абстрактных или экспериментальных ситуациях, и об именах by-id, когда речь зайдёт о практических примерах применения ZFS.
Для практического использования ZFS on Linux перво-наперво необходимо обеспечить её поддержку в вашем дистрибутиве – ибо по причинам, описанным в предыдущей статье, сама собой она не поддержится ни в одном Linux’е.
Как это сделать, зависит от дистрибутива. В Сети можно найти подробные инструкции для Ubuntu и Gentoo, которые легко распространяются на клоны обеих систем. Не столько инструкции, сколько руководства к самостоятельному действию имеются на сайте проекта ZFS on Linux для абстрактных RPM- и Deb-based дистрибутивов. Я же расскажу о том, как это делается в openSUSE релизов 12.1 и 12.2.
Как вы наверняка догадались, ZFS не поддерживается в openSUSE ни «искаропки», ни в официальных репозиториях. Но зато в репозиториях неофициальных, так называемых «домашних», пакеты её поддержки представлены аж в двух экземплярах: в mUNIX9 и в ghaskins. Точные их адреса легко найти через систему OBS (Open Builging System) по ключевому слову zfs.
Какому из репозиториев отдать предпочтение – вопрос спорный. Первые свои опыты с ZFS on Linux я проводил, основываясь на пакетах из mUNIX9. И они прошли без всяких осложнений, хотя и велись в сугубо экспериментальном режиме. Однако к моменту понимания, что эта система для меня – «всерьёз и надолго», последняя тогда версия zfs имелась только в репозитории ghaskins. Однако его использование требует некоторых дополнительных манипуляций.
Кроме того, в репозитории ghaskins на данный момент имеются пакеты только для openSUSE релизов 12.1 и 12.2. Репозиторий же mUNIX9 охватывает все актуальные ныне версии SLE и openSUSE. включая Tumbleweed и Factory.
Различаются репозитории и набором пакетов. В ghaskins, кроме «рабочих» модулей zfs и spl для ядра default, можно видеть массу отладочных их сборок (рис. 1).
В репозитории mUNIX9 с этим существенно скромнее – имеются модули только для ядра default и для xen (рис. 2)
Так что окончательный выбор я предоставляю читателю. Но на какой бы репозиторий он ни пал, его следует подключить. И сделать это можно любым из трёх способов. Первый – с помощью zypper’а:
# zypper ar -f [URL] [Name]
Второй способ – через модуль Репозитории... центра управления YaST2 посредством кнопки Добавить (рис. 3):
выбора пункта Указать URL (рис. 4):
и ввода необходимых значений в поля Имя репозитория и URL (рис. 5):
Наконец, третий способ, для самых ленивых – отыскать пакеты zfs, spl и сопутствующие через OBS и прибегнуть к «установке в один клик». В этом случае подключение репозиториев будет совмещено с установкой пакетов.
В первых двух же вариантах после подключения репозитория надо будет установить (с помощью zypper’а или модуля управления пакетами YaST’а) следующее (пример дан для репозитория mUNIX9, но из ghaskins потребуются те же компоненты):
Возможно, не вредным окажется и пакет zfs-test. А вот zfs-dracut, предназначенный для создания initrd с поддержкой ZFS, несмотря на его потенциальную нужность, установить не удастся: требуемый для него пакет dracut в openSUSE пока не поддерживается.
Следует учесть, что при использовании ядра kernel-desktop (а скорее всего, так оно и есть) пакет zfs-kmp-default потянет за собой и соответствующее ядро kernel-default. Пункт загрузки которого будет внесён в меню GRUB, но не будет отмечен как умолчальный – этим надо озаботиться самому.
И, наконец, при использовании пакетов из ghaskins потребуется, скорее всего, сделать в каталогах /etc/init.d/rc3.d и /etc/init.d/rc5.d символические ссылки на файл /etc/init.d/zfs. Иначе файловые системы ZFS, к созданию которых мы приближаемся, не будут автоматически монтироваться при старте и размонтироваться при останове системы.
При использовании репозитория mUNIX9 эти действия будут нечувствительно выполнены в ходе установки пакетов.
Вот теперь можно приступать к применению ZFS в мирных практических целях.
Освоив ранее основные понятия, мы научились понимать ZFS. Для обратной же задачи – чтобы ZFS понимала нас – нужно ознакомиться с её командами. Главные из них – две: zpool для создания и управления пулами, и zfs для создания и управления наборами данных. Немного, правда? Хотя каждая из этих команд включает множество субкоманд, с которыми мы со временем разберёмся. Очевидно, что работу с ZFS следует начинать с создания пула хранения. Начнём с этого и мы. В простейшем случае однодисковой конфигурации это делается так:
