Алексей Федорчук - Linux Mint и его Cinnamon. Очерки применителя
Для чего, как нетрудно догадаться, требуется установка пакета mdadm, в ходе которого автоматически выполняется сканирование на предмет наличия softRAID'а. И после рестарта машины нужные модули (raid# и всё, что с ними связано) загружаются автоматически, появляется устройство /dev/md0.
Теперь остаётся определить устройство /dev/md0 на его законное место — я уже несколько лет держу свои рабочие данные на отдельном носителе (разделе, на пуле ZFS или, как в примере, на программном RAID'е), который монтируется в каталог /home/data. Каковой был немедленно создан, и командой chown ему были присвоены атрибуты принадлежности alv:alv (точнее, 1000:1000 — UID и GID моего главного рабочего пользователя, вне зависимости от того, как его зовут и какова его основная группа). Затем командой
$ sudo blkid
для устройства /dev/md0 был определён его UUID, под которым он был вписан в /etc/fstab строкой вида
UUID=очень-длинное-бла-бла-бла /home/data ext4 defaults,noatime 0 0
Разумеется, можно было обойтись и без UUID, занеся RAID под его так называемым именем верхнего уровня, то есть /dev/md0. Но уж раз в Ubuntu и её потомках принято именование устройств по UUID'у — будем придерживаться фирменного стиля.
Сказанное выше относилось к подключению уже существующего softRAID Level 0. Однако создание последнего «с нуля» ничуть не сложнее. Для начала с помощью одной из утилит, fdisk или cfdisk на каждом из носителей, предназначенных для включения в массив, создаются по разделу. Для обоих следовало устанавливается идентификатор типа файловой системы fd — Linux raid autodetect.
Эти действия можно проделать с помощью графической утилиты gnome-disks, задав при создании разделов идентификатор их типа вручную, как 0xfd:
Или, если не обременять память этим сложным шестнадцатеричным числом, выбрать его из списка, выводимого через пункт Изменить раздел, вызываемый «нижней шестерёнкой»:
Дальнейшая работа выполняется с помощью утилиты mdadm, которая в моём случае была запущена в такой форме:
$ sudo mdadm --create /dev/md0 --auto=yes --level=0 --raid-devices=2 /dev/sd(a,b)2
Здесь --create (или -C) — субкоманда создания массива, в качестве аргумента которой указывается имя его файла устройства (к этому вопросу я ещё вернусь), --level — определение его уровня (а я уже говорил, что именно нужно народу), --raid-devices — число входящих в массив устройств с указанием их имён (/dev/sda2 и /dev/sdb2). Опция же --auto=yes, как было установлено эмпирическим путём, препятсвует переопределению имени файла RAID-устройства.
ТПосле создания RAID'а результат своих действий можно проверить таким образом:
$ sudo 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'а, на нём следует создать файловую систему, например, так:
$ sudo mkfs.ext4 /dev/md0
И обеспечить её монтирование при старте машины, внеся в файл /etc/fstab строку такого вида:
UUID=очень-длинное-бла-бла-бла /home/data ext4 defaults,noatime 0 0
Где очень-длинное-бла-бла-бла, как и раньше, определяется командой
$ sudo blkid
которая выведет значения UUID для всех наличных накопителей.
Mint и LVM
Тема этого очерка образовалась в значительной мере как результат случайности. Которая началась с того, что я стал счастливым обладателем SSD-накопителя производства Crucial MX100 объёмом 512 ГБ, и в результате дисковая подсистема, упакованная внутри моего десктопа, стала выглядеть так:
• вышеупомянутый полутерабайтный Crucial — на первом SATA-разъёме;
• SanDisk Extreme SSD, 120 Гбайт — на втором;
• он же, то есть точно такой же — на третьем;
• традиционный винчестер Seagate ST3500410AS о 500-х гигабайтах — на четвёртом.
Первый SSD в ходе установки Mint 17.1 Rebecca был разбит на три раздела:
• /dev/sda1 объёмом 20 ГБ с файловой системой ext4 под корень файловой иерархии;
• /dev/sda2 объёмом 10 ГБ, также с ext4 — под каталог будущего пользователя, то есть меня — /home/alv (в домашнем каталоге я храню только dot-файлы и некоторые служебные данные, на что указанного объёма хватало с лихвой);
• /dev/sda3 на всё оставшееся пространство — без файловой системы и, сооветственно, без точки монтирования.
На обоих SanDisk'ах было создано по разделу, занимающему их целиком (/dev/sdb1 и /dev/sdc1, соответственно), также без файловой системы. Вместе с /dev/sda3 они предназначались для объединения в хренилище моих рабочих данных — организация оного и является предметом данных очерков.
Винчестер у меня служит для экспериментальных целей, и потому разметка его постоянно меняется, да и к нашей теме не относится. За исключением того, что первые 32 ГБ диска выделены в раздел/dev/sdd1, служащий swap'ом для всех моих систем.
Очевидно, что организация хранилища из трёх устройств требовала их объединения тем или иным способом. И поначалу напрашивался выбор ZFS: эту систему хранения данных я люблю, более-менее знаю, и включал её поддержку в сборки своих вариантов Mint 17. Однако тут модули ZFS у меня неожиданно с первого раза не собрались. Правда, проблема решилась (благодаря помощи Станислава Шрамко aka stanis, о чём пойдёт речь в следующем очерке), однако, как говорится, осадок остался. Ибо случай этот послужил напоминанием не только о бренности бытия, но и птичьих правах, на которых существует ZFS on Linux.
В своё время, более десяти лет назад, я очень увлекался технологией LVM, тогда ещё 1-й версии. Потом я это дело забросил по двум причинам. Во-первых, во времена винчестеров с PATA-интерфейсом было очень сложно сконфигурировать многодисковую систему LVM без деградации производительности. Во-вторых, инструментарий CLI для создания такой системы и последующего управления ею показался мне при использовании в «домашних» условиях неоправданно сложным — особенно в сравнении с появившейся вскоре ZFS.
Ныне, в эпозу безраздельного господства SATA-накопителей, первое препятствие к применению LVM отпало полностью. Что касается второго, то оно во многом сглаживается наличием графических оболочек, изолирующих применителя от низкоуровневых команд. Одну из которых system-config-lvm, я и использовал нынче.
С тех пор, как я имел дело с LVM, появилась LVM2, предоставляющая ряд дополнительных возможностей, таких, как расширение логического тома на вновь подключённые физические тома. Однако суть технологии, терминология, утилиты CLI для работы с LVM почти не изменились. Да и в сети можно найти много не менее подробных, но более свежих материалов по теме. Так что на этих вопросах останавливаться не буду, ограничившись маленьким терминологическим конспектом.
Сама по себе система LVM — уровень абстракции между физическими носителями (дисками, их разделами и массивами) и обычными файловыми системами. Она позволяет объединять в логические тома разделы с разных дисков, изменять их размер в сторону увеличения (за счёт присоединения новых накопителей) и, с некоторыми оговорками, уменьшения. В основе её лежит понятие физического тома (PV — Physical volume). Это — обычный дисковый раздел, для которого устанавливается идентификатор типа (ID) 8e. Вопреки написанному в некоторых сетевых материалах, целый диск как raw-устройство типа /dev/sd? в качестве физического тома выступать не может. Другое дело, что созданный на нём раздел с ID 8e может занимать и весь диск и даже RAID, программный или аппаратный.
Физический том делится на «куски», именуемые физическими экстентами (Physical Extent, PE — по традиции оставлю этот термин без перевода, так как предлагаемый русскоязычной Википедией диапазон может ввести в заблуждение). Это — нечто вроде аналогов физических блоков (секторов) обычного винчестера, их размер по умолчанию 4 МБ, но может быть изменён в обе стороны.
