Про Salix. Поддержка softRAID

Алексей Федорчук

До сих пор я применял Salix установленным на экспериментальный винчестер, подключив к нему в качестве хранилища своих рабочих данных ранее существовавший пул ZFS. И всё было замечательно, кроме чувства обиды: Ubuntu, которой я практически перестал пользоваться, занимает целых два SSD, а благородный Salix ютится на жалком разделе утильного HDD. Несправедливость эта должна быть исправлена — и я взялся за её исправление.

Попутно начитался всяко разных материалов о несравненных достоинствах XFS, в её современной инкарнации объявленной одной из файловых систем будущего. Столь громкое заявление нуждалось в проверке. Ранее я часто использовал её, и впечатления были противоречивые (но это будет темой отдельной истории). Одно уяснилось точно: в полном блеске она показывает себя только на многодисковых конфигурациях — то есть RAID’ах. Поскольку свой чипсетный fake RAID я уже пытался применять с результатом, далёким от восторгов, встал вопрос об использовании RAID’а программного.

В инсталляторе Salix’а поддержка создания программного RAID’а штатным расписанием не предусмотрена. Однако её можно выполнить руками, ибо ядро, загружаемое с установочного носителя по умолчанию, содержит всё, что для этого нужно. Зачем? Вопрос, нужен ли RAID народу, и если нужен — то какой, да и какие ветви файловой иерархии на нём размещать, я здесь обсуждать не буду, ибо неоднократно высказывался по этому поводу (например, здесь и здесь). А потому, ввиду предполагаемого в дальнейшем использования XFS, буду исходить из следующих постулатов:

  • народу (в лице одного из его лучших представителей) RAID нужен позарез;
  • он необходим ему в форме softRAID Level 0;
  • размещаться на нём должна ветка /home файлового древа.

Засучив рукава и изготовив установочную по SD-карточке обоими описанными недавно способами, я взялся за дело. Для начала, загрузившись поочерёдно с одной, потом с другой карточки (чисто для проверки — результат был неизменно превосходен в обоих случаях), я при первой же возможности вышел из инсталлятора:

salix_003И оказался в среде командной оболочки с привилегиями root’а. Где для начала занялся разметкой диска, по привычке обратившись для этого к утилите fdisk. Однако при желании можно воспользоваться cfdisk или, если целевые диски размечены в GPT-стиле, одним из аналогов — gdisk или cgdisk, всё это в среде установочного носителя доступно. Есть там и универсальная утилита parted — но это только для тех медам и мсье, которые знают толк в извращениях.

Кстати, открою страшную тайну: (почти) все описанные в дальнейшем действия можно выполнить с любого Live-носителя «ремонтного» назначения, типа Parted Magic или GParted. И даже из Linux-системы, установленной на другом диске. Причём сделать это с помощью графической утилиты Gparted — с одной оговоркой, которая перечёркивает весь комфорт этого пути.

Итак, с помощью fdisk я создал на каждом из моих SSD две раздела:

  • /dev/sda1 и /dev/sdb1 по 20 ГБ каждый; первый предназначался под корень файловой системы Salix, второй оставил в запасе — а вдруг мне ещё чего-нибудь захочется установить;
  • /dev/sda2 и /dev/sdb2 на всё оставшееся пространство (по 93 «настоящих» гигабайт); они-то и предназначались для объединения в программный RAID.

В связи с эти обращаю внимание на важный момент: для обоих последних разделов следовало установить идентификатор типа файловой системы fd — Linux raid autodetect. Это легко сделать при использовании fdisk или cfdisk (как и их аналогов gdisk и cgdisk), но не получится в GParted. Так что для завершения процедуры всё равно потребуется одна из указанных утилит, что вызывает резонный вопрос: а за каким зелёным городить огород с графическим фронт-эндом?

Закончив с разметкой диска, я принялся за создание программного RAID’а. Это делается с помощью утилиты mdadm, которая в моём случае была запущена в такой форме:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sd[a,b]2

Здесь --create (или -C) — субкоманда создания массива, в качестве аргумента которой указывается имя его файла устройства (к этому вопросу я ещё вернусь), --level — определение его уровня (а я уже говорил, что именно нужно народу), --raid-devices — число входящих в массив устройств с указанием их имён (/dev/sda2 и /dev/sdb2).

При задании имени устройства для массива я, исходя из банальной логики, задал, как в примере, /dev/md0. Это же устройство было окучено в процессе инсталляции как /home и прописано в /etc/fstab. Однако после рестарта оно волшебным образом превратилось в симлинк на /dev/md127, и, соответственно, мой домашний каталог при этом потерялся.

Я решил эту задачу «лобовым напором» — изменением имени устройства в /etc/fstab. Однако потом в сети обнаружил, что в некоторых дистрибутивах (например, в Ubuntu) изменение имени RAID-устройства после перезагрузки может стать большой проблемой. Немало подивившись этому обстоятельству, я зато нашёл и решение, претендующее на «правильность»: директиву на создание массива следует давать с опцией --auto=yes. То есть — вот так:

# mdadm --create /dev/md# --auto=yes --level=0 --raid-devices=2 /dev/sd[a,b]2

Поскольку мой RAID был уже создан, я потренировался на кошечках двух одинаковых флешках — и обнаружил, что это действительно так: имя устройства (в моём случае /dev/md1) оставалось неизменным после перезагрузки. Так что что директиву mdadm нужно давать именно в такой форме — разумеется, с подстановкой своих реалий, типа имён «райдируемых» устройств.

Так или иначе, после создания RAID’а результат своих действий можно проверить таким образом:

# mdadm --detail /dev/md0

Что должно дать примерно такой вывод:

/dev/md0:
        Version : 1.2
  Creation Time : Tue Apr 15 00:06:59 2014
     Raid Level : raid0
     Array Size : 195371008 (186.32 GiB 200.06 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Tue Apr 15 00:06:59 2014
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : salix:0
           UUID : a32dc435:25c68870:18fa63ca:010d8910
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2

Вместо субкоманды --detail можно использовать её сокращённую форму -D. И заметка на будущее: все утилиты субкоманды mdadm, даже не выполняющие никаких действий, а только выводящие информацию, требуют прав суперпользователя. Исключение — запрос помощи

$ mdadm --help

и детализирующие его просьбы типа

$ mdadm --create --help

К слову, в выводе последнего запроса (или из man mdadm) можно узнать о дополнительных опциях, с помощью которых определяются, например, такие параметры, как величина блока «распараллеливания» (Chunk Size), которая теоретически должна влиять на быстродействие (чем больше, тем лучше), Однако сведений, насколько это чувствительно в десктопной обстановке, я не нашёл, и потому положился на умолчание mdadm; как можно видеть из вывода субкоманды -D, оно составляет 512 Кбайт (в старых версиях — 64 Кбайт).

Завершив создание RAID’а, я бестрепетно ввёл в командной строке волшебное слово setup — и оказался снова в программе инсталляции. Каковая прошла столь же беспроблемно, как и ранее — только в этот раз я из лени выбрал вариант полной установки. Единственный момент, требующий внимания — не забыть после определения корневого раздела (в моём случае /dev/sda1) и его форматирования, то есть после этой стадии

salix_008не забыть выбрать для форматирования и монтирования устройство программного RAID’а (тогда в списке доступных оно фигурировало ещё под именем /dev/md0 — и под ним же попало в /etc/fstab).

Как я уже говорил в самом начале, одной из целей проведённого мероприятия было наблюдение за XFS в современных условиях, поэтому для /home на RAID’е она и была выбрана. Заодно и корень файловой иерархии я отформатировал в ней же, следуя умолчанию инсталлятора. Ибо за время знакомства с Salix’ом понял, что эти мужики плохого не посоветуют.

На этом, собственно, можно и закончить историю о подключении к Salix’у программного RAID’а. Потому что про завершающий её эпизод — необходимость правки /etc/fstab, возникшую вследствие моего недостаточного внимания к трудам предшественников, я уже сказал. А вот как softRAID и XFS сказались на быстродействии файловых операций — расскажу в ближайшее время. Пока замечу только, что весьма неожиданным для меня образом.

Оглавление