Читать онлайн «Linux Mint и его Cinnamon. Очерки применителя». Страница 89

А вот об именах физических устройств, включаемых в пул, следует сказать особо.

В современном Linux’е использование для накопителей имён «верхнего уровня», имеющих вид /dev/sda, не является обязательным, а в некоторых случаях и просто нежелательно. Однако правила менеджера устройств udev позволяют определять и другие модели идентификации накопителей:

   • метке тома (/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 определяются не условиями его подключения или какими-то правилам, а задаются производителем и жёстко прошиты в «железе». И потому эта модель является наиболее однозначной для именования устройств. А также, что немаловажно, строится по понятной человеку логике.

Какую из моделей именования устройств выбрать для данного пула — зависит от его назначения и масштабов. Имена «верхнего уровня» целесообразно применять для однодисковых пулов (особенно если в машине второго диска нет и не предвидится). Они же, по причине простоты и удобопонятности, рекомендуются для экспериментальных и разрабатываемых пулов. И очень не рекомендуются — во всех остальных случаях, так как зависят от условий подключения накопителей.

Этого недостатка лишена модель by-id: как пишет Брайан, при её использовании «диски можно отключить, случайно смешать и подключить опять произвольным образом — и пул будет по-прежнему корректно работать». Как недостаток её рассматривается сложность конфигурирования больших пулов с избыточностью. И потому она рекомендуется для применения в «десктопных» и «квартирных» (типа семейного сервера) условиях.

Для больших (более 10 устройств) пулов из дисков, подключённых к нескольким контроллерам, рекомендуется идентификация by-path. Однако в наших целях она громоздка и избыточна.

Наконец, ZFS on Linux предлагает и собственную модель идентификации — /dev/disk/zpool, в котором именам by-path ставятся в соответствие уникальные и осмысленные «человекочитаемые» имена, даваемые пользователем. Модель эта рекомендуется для очень больших пулов, каковых на настольной машине ожидать трудно.

Так что дальше я буду использовать имена «верхнего уровня», говоря об абстрактных или экспериментальных ситуациях, и об именах by-id, когда речь зайдёт о практических примерах применения ZFS.

Для практического использования ZFS on Linux перво-наперво необходимо обеспечить её поддержку в вашем дистрибутиве — ибо по причинам, описанным ранее, сама собой она не поддержится ни в одном Linux’е.

Как это сделать, зависит от дистрибутива. В Сети можно найти подробные инструкции для Ubuntu, которые легко распространяются на все производные от неё системы, в том числе и на Mint.

Как уже было сказано, пакеты поддержки ZFS представлены в PPA-репозитори, где они реализованы в виде сценариев dkms, предполагающих сборку модулей под текущую версию ядра. Пакеты эти объединены в метапакет zfs-native, существующий в двух варианта — ZFS Stable Releases и ZFS Daily Releases, то есть стабильной и тестовой сборках, соответственно.

Для использования ZFS в Ubuntu для начала нужно подключить нужный PPA-репозиторий. Поскольку все последующие действия потребуют прав суперпользователя, перво-наперво обретаем их на длительное время командой

$ sudo -i

с вводом пользовательского пароля. А затем собственно подключаем репозиторий:

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

Или, при желании поэкспериментировать --

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

Обновляем кэш:

# apt update

Теперь строим дерево зависимостей — в Mint 17.1 Rebecca это обязательный шаг, хотя ранее я обходился без него:

# apt build-dep ubuntu-zfs

И собираем необходимые пакеты:

# apt install ubuntu-zfs

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

# modprobe zfs

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

# lsmod | grep zfs

вывод которой будет выглядеть примерно так:

zfs                  1158757  4

zcommon                51283  1 zfs

znvpair                81997  2 zfs,zcommon

zavl                   15011  1 zfs

zunicode              331226  1 zfs

spl                    88617  5 zfs,zcommon,znvpair,zavl,zunicode

После чего остаётся создать точку монтирования для пула ZFS — в моём случае таким образом:

# mkdir /home/data

Дать ей атрибуты принадлежности обычному пользователю:

# chown -R alv:alv /home/data

Теперь можно приступать к применению ZFS в мирных практических целях.

Освоив ранее основные понятия, мы научились понимать ZFS. Для обратной же задачи — чтобы ZFS понимала нас — нужно ознакомиться с её командами. Главные из них — две: zpool для создания и управления пулами, и zfs для создания и управления наборами данных. Немного, правда? Хотя каждая из этих команд включает множество субкоманд, с которыми мы со временем разберёмся.

Очевидно, что работу с ZFS следует начинать с создания пула хранения. Начнём с этого и мы. В простейшем случае однодисковой конфигурации это делается так:

# zpool create tank dev_name

Здесь create — субкоманда очевидного назначня, tank — имя создаваемого пула (оно обычно даётся в примерах, но на самом деле может быть любым — с учётом ограничений ZFS, я использую имя data), а dev_name — имя устройства, включаемого в пул. Каковое может строиться по любой из описанных ранее моделей. И, чтобы не повторяться, напомню: все команды по манипуляции с пулами и наборами данных в них выполняются от лица администратора.

В случае, если в состав пула включается один диск, и второго не предвидится, можно использовать имя устройства верхнего уровня — например, sda для цельного устройства (обратим внимание, что путь к файлу устройства указывать не нужно). Однако реально такая ситуация маловероятна: загрузка с ZFS проблематична, так что как минимум потребуется раздел с традиционной файловой системой под /boot (и/или под корень файловой иерархии), так что команда примет вид вроде следующего:

# zpool create data sda3

Однако если можно ожидать в дальнейшем подсоединения новых накопителей и их включения в существующий пул, то лучше воспользоваться именем по модели by-id, например:

# zpool create data ata-Crucial_CT512MX100SSD1_14330CEEA98C-part3

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

# zpool create data dev_name1 dev_name2

где dev_name1 и dev_name1 — имена устройств в принятой модели именования.

В приведённом примере будет создано нечто вроде RAID’а нулевого уровня, с расщеплением (stripping) данных на оба устройства. Каковыми могут быть как дисковые разделы, так и диски целиком. Причём, в отличие от RAID0, диски (или разделы) не обязаны быть одинакового размера.

После указанной команды никаких сообщений не последует. No news — good news, говорят англичане; в данном случае это означает, что пул был благополучно создан. В чём можно немедленно убедиться двумя способами. Во-первых, в корневом каталоге появляется точка его монтирования /data. А во-вторых, этой цели послужит субкоманда status: # zpool status data

которая выведет нечто вроде этого: