Linux Mint и его Cinnamon. Очерки применителя. Часть 10

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

Следующие три очерка посвящаются рассмотрению довольно специальных вопросов — применению в Mint технологии LVM, программного RAID и системы размещения данных ZFS. Тех, кого эти темы не интересуют, могут смело пропустить соответствующие страницы.

softRAID, LVM, ZFS: общее введение

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

  1. программный RAID, позволяющий повысить быстродействие дисковой подсистемы (softRAID Level 0);
  2. технология LVM, дающая возможность простого подключения дополнительных носителей и, при соблюдении некоторых условий, изменения размера файловых систем;
  3. система размещения данных ZFS, объединяющая в себе функции управления логическими томами и файловой системы.

Возможны и другие варианты, например, softRAID Level 1, обеспечивающий, опять же при некоторых условиях, надёжность хранения данных, или файловая система BTRFS, функцйионально сходная с ZFS. Однако первое решение для настольной машины (а в данных очерках рассматривается только этот случай, о серверах тут речи не будет) имеет не много смысла. Ибо эта самая надёжность гарантируется только тогда, когда есть возможность замены вышедшего из сторя диска аналогичным по объёму и, желательно, характеристикам — согласитесь, не частое явление для индивидуала-надомника.

Что же до BTRFS — что бы ни говорили о готовности этой системы к промышленному использованию (а настольная машина применителя для него самое что ни на есть промышленное использование), на сей счёт в народе (в том числе и у автора этих строк) существуют небезосновательные сомнения. Характерно, что в openSUSE, кажется, первой взявшей BTRFS на вооружение как умолчальной, она задействуется под корневую файловую систему, тогда как бесценные пользовательские данные по умолчанию предлагается размещать на XFS.

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

И ещё одна необходимая оговорка: все три варианта я рассматриваю исключительно в контексте хранения пользовательских данных, то есть, фигурально говоря, ветви /home файловой иерархии. Предполагается, что корень последней размещён на обычном дисковом разделе с традиционной файловой системой, которая, как говаривал Генри Форд Старший, может быть любой. При условии, что это будет Ext4, ибо все остальные нынче не дадут применителю ничего, кроме возможных проблем, в причины возникновения которых здесь вдаваться неуместно. А вот сказать пару слов об иструментах дисковой разметки — необходимо.

Инструменты дисковой разметки и форматирования

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

Виды дисковой разметки

Некогда тема дисковых разделов подробно рассматривалась в любом руководстве по Linux и соплеменным системам, а также во множестве специальных документов, как в Сети, так и на бумаге. С этой процедуры начинало знакомство с Linux не одно поколение грядущих его применителей. А устрашающие к ней комментарии были непременным атрибутом «курса молодого линуксоида».

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

  1. разметка в стиле msdos;
  2. разметка в стиле gpt;
  3. полварианта для любителей и ценителей — разметка в стиле bsd.

На полуварианте останавливаться не буду — те, кто держит на своей машине Linux параллельно с какой-либо BSD-системой, знают о нём не меньше меня. Тем более, что это, как и msdos, частный случай MBR-разметки, о которой сказать необходимо.

Разметка в стиле msdos возникла вместе с первыми IBM PC и их BIOS, предусматривающим Главную Загрузочную Запись (MBR — Master Boot Record). Она целиком умещается в так называемый нулевой сектор носителя, объёмом 512 байт. И в его части, отведённой под таблицу разделов, предусмотрено место для четырёх записей — то есть Primary Partitions. Большее количество разделов можно создать по «матрёшечному» принципу, путём объявления одного из первичных разделов Extended Partition.

Расширенный раздел выступает в качестве контейнера, в который последовательно, как в матрёшку, вкладываются один логический раздел и ещё один расширенный раздел. Последний, в свою очередь, выступает контейнером второго уровня, и может включать еще один логический раздел и следующий по очереди расширенный, — и так до бесконечности. Правда, аналогия с матрёшкой — не совсем строгая, потому что для пользователя все эти вложенные разделы видятся как равноправные части «головного» Extended-раздела. Да и на счёт бесконечности — тоже несколько преувеличено: на самом деле существует практический лимит для восприятия логических разделов, определяемый числом 63.

Разметка в стиле GPT (GUID Partition Table) — это новый формат таблицы разделов на носителях информации (традиционных винчестерах, SSD-накопителях, флэшках, SD-картах). Как явствует из названия, он основан на Globally Unique Identifier (GUID) — статистически уникальных 128-битных идентификаторах всего на свете, в том числе и носителей.

Таблица разделов GUID (далее для краткости я буду называть её просто GPT) существенно больше, нежели MBR.. Она занимает первые 34 блока (с нулевого по 33-й). Из них нулевой блок занимает всё тот же MBR — точнее, его защищённая (или защищающая? — protected) копия, предназначенная для программ, не понимающих GPT. Благодаря ему, скажем, утилита fdisk опознаёт винчестер с GPT как единый раздел неизвестного типа, но на самом деле работать с ним не может.

Следующий блок — это оглавление таблицы разделов, в котором предусмотрено место для 128 записей. Это, соответственно, максимальное число разделов при разметке в GPT-стиле. Наконец, остальные 32 блока предназначены для записи данных о разделах.

Таблица разделов GUID существует в двух экземплярах: основной находится в первых 34 блоках носителя, а дублирующий (полная копия основного, за исключением MBR) — в последних. При повреждении основной GPT (фиксируемом несовпадением контрольной суммы, хранящейся в оглавлении) она автоматически восстанавливается из таблицы дублирующей.

В Linux традиционно использовалась MBR-разметка в стиле msdos, и для последней предназначались соответствующие утилиты.

Несколько лет назад казалось, что железный конь GPT уверенно идёт на смену крестьянской лошади MBR: инсталляторы ряда популярных дистрибутивов, на которые не будем указывать пальцем, стали предлагать разметку в GPT-стиле как альтернативу, а некоторые — даже и по умолчанию. Однако довольно быстро оказалось, что это не даёт применителю ничего полезного, а вот некоторые проблемы с загрузчиком и особенно его восстановлением при сбоях создаёт. И даже самые прогрессисты от дистроения откатились обратно, сохранив поддержку GPT лишь в качестве опции.

Надо сказать, что Ubuntu и её последователи не поддавались модному влиянию, и в инсталляторах всего этого клана GPT-разметка не поддерживалась никогда, и не поддерживается по сию пору. Хотя с дисками, размеченными в GPT-стиле внешними программами все Ubuntu’иды работают вполне справно. Однако далее я буду говорить только про MBR-разметку — интересующимся прогрессом ради прогресса могу предложить почитать вот это.

CLI: инструменты разметки

В Linux для разметки диска в MBR-стиле из командной строки можно использовать:

  • низкоуровневую утилиту командной строки sfdisk — инструмент очень гибкий, но сложный в обращении и требующий очень большой аккуратности — все изменения дисковой разметки совершаются там в реальном времени;
  • интерактивную диалоговую программу fdisk — почти столь же гибкую, как и sfdisk, но более простую и, главное, более безопасную в обращении — изменения дисковой разметки происходят тут только после соответствующего подтверждения пользователем правильности своих действий;
  • интерактивную меню-ориентированную программу cfdisk, которая считается еще более простой в использовании, чем fdisk (для которого она служит фронт-эндом) и столь же безопасна с точки зрения сохранности данных;

Кроме этого, существует универсальная утилита parted, которая позволяет создавать не только дисковые разделы, но и файловые системы на них. В числе её функций также модифицирование существующих разделов — изменение размера, копирование и перемещение. Однако платой за её универсализм является сложность использования без постоянной практики. А поскольку разметка диска — не то занятие, которому тпичный применитель Linux’а предаётся по три раза на дню, говорить о ней я не буду.

Утилита fdisk

Начнем с fdisk: именно им больше всего пугали в старые времена начинающих пользователей Linux, предлагая дружественные альтернативы типа Disk Druid. Однако при ближайшем рассмотрении выясняется, что ничего устрашающего в ней нет.

Происхождение fdisk теряется во мраке веков, уходя во времена первых UNIX для PC-архитектуры — насколько я понимаю, раньше необходимости в ней не было, а главными инструментами дисковой разметки были утилиты типа disklabel или bsdlabel. Мне не удалось также выяснить, когда эта утилита появилась в Linux. Могу только предполагать, что на самых ранних стадиях создания утилит обрамления для его ядра — т.н. linux-utils.

Для начала следует запомнить, что запуск команды fdisk в любом качестве, даже просто для получения информации о диске, возможно только с правами суперпользователя, каковые и надо обеспечить себе обычным для Mint образом, то есть через sudo.

Если команду fdisk дать без опций и аргументов, она выведет краткую справку об её использовании:

$ sudo fdisk

Usage: fdisk (-l) (-b SSZ) (-u) device
E.g.: fdisk /dev/hda  (for the first IDE disk)
  or: fdisk /dev/sdc  (for the third SCSI disk)
  or: fdisk /dev/eda  (for the first PS/2 ESDI drive)
  or: fdisk /dev/rd/c0d0  or: fdisk /dev/ida/c0d0  (for RAID devices)

В качестве аргумента команды фигурирует имя файла устройства — физического диска целиком. Поскольку в современных версиях ядра Linux все диски, вне зависимости от их интерфейсов (PATA, SATA, SCSI, SAS, USB) определяются единой подсистемой ATA-SCSI, на самом деле имена эти будут иметь вид /dev/sda, /dev/sdb и так далее.

Смысл опций команды fdisk следующий:

  • l не предписывает выполнения каких-либо действий, а лишь выводит информацию о диске и его разделах, если таковые имеются;
  • b задаёт размер блока — единицы измерения дискового пространства; по умолчанию, без указание этой опции, он равен физическому блоку (512 байт), прочие возможные значения кратны его размеру — 1024, 2048 или 4096 байт;
  • u запускает fdisk, являясь опцией по умолчанию.

Перво-наперво посмотрим на информационную функцию fdisk, для чего запустим её следующим образом:

$ sudo  fdisk -l /dev/sdd

Ответом будет вывод примерно такого вида:

Диск /dev/sdd: 500.1 Гб, 500107862016 байт
255 головок, 63 секторов/треков, 60801 цилиндров, всего 976773168 секторов
Units = секторы of 1 * 512 = 512 bytes
Размер сектора (логического/физического): 512 байт / 512 байт
I/O size (minimum/optimal): 512 bytes / 512 bytes
Идентификатор диска: 0x000b24d0

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sdd1            2048   629147647   314572800    5  Расширенный
/dev/sdd2       629149696   746337195    58593750   83  Linux
/dev/sdd3       746337196   863525803    58594304   83  Linux
/dev/sdd4       863525804   976773167    56623682   83  Linux
/dev/sdd5            2111    62504095    31250992+  82  Linux своп / Solaris

Если опустить аргумент команды, то аналогичные сведения будут выведены для всех физических дисков данной машины: сначала — общая информация о диске, включающая его размер, число головок, секторов и цилиндров, а затем для каждого существующего на диске раздела указываются его первый и последний цилиндры (символом + маркируются разделы, не занимающие последний цилиндр полностью), размер в блоках (физических или заданных опцией b), идентификатор типа файловой системы и его название.

Для каких-либо манипуляций с дисковыми разделами команду fdisk следует запустить в интерактивном режиме:

# fdisk /dev/sdd

Что можно сделать без всяких опций, но вот указание аргумента тут будет обязательным.

После этого мы получаем в свое распоряжение некий интерфейс, требующий ввода определенной команды, исполнение которой сводится к ответу на несколько вопросов. С полным списком доступных команд можно ознакомиться благодаря прекрасной системе помощи, вызываемой командой m.

Так, команда p выведет текущий список дисковых разделов с указанием их типа и размера. Далее, разделы можно создавать (командой n) или удалять (командой d), однако до команды записи изменений (w) никаких необратимых действий, могущих разрушить ранее существовавшую разметку (и, соответственно, файловые системы и данные, к ней привязанные), не последует: неудачно созданные разделы можно удалить и на их месте создать новые. И в любой момент командой q можно без всяких последствий выйти из программы.

При создании раздела средствами fdisk сначала определяется, будет он первичным (primary) или расширенным (extended). Рассмотрим сначала первый случай. При нем далее просто указывается номер раздела (от 1 до 4). В этих пределах номер может быть любым — можно сначала создать раздел 2, а потом 1, или даже весь диск отвести под раздел 4. Номер раздела останется на века: именно он будет идентифицировать файл устройства, соответствующий созданному разделу (например, /dev/sda2, или /dev/sdb1).

Далее задается начальный цилиндр создаваемого раздела (по умолчанию — первый свободный, для пустого диска — просто первый). Однако никто не мешает указать любой другой цилиндр в качестве стартового (на неразбитом пространстве, разумеется). А потом — конечный цилиндр (по умолчанию — последний физический на неразбитом дисковом пространстве), или просто размер раздела в каких-либо общепринятых единицах измерения информации, например, +300M; и +, и M (или что-либо аналогичное) — обязательны, иначе объем диска окажется равных ровно трёхстам цилиндрам.

В современных версиях  fdisk возможно указание объема в двух системах единиц (не считая цилиндров). Во-первых, он может задаваться в том, что мы испокон веков привыкли называть мегабайтами и гигабайтами, то есть степенях двойки. Однако ныне авторитетные товарищи утверждают, что такие единицы измерения должны величаться мебибайтами, гибибайтами и так далее. Их следует указывать так: +1000MB, +10GB и так далее.

А можно определять объём раздела и в «настоящих», с точки зрения пуристов от метрологии, мегабайтах и гигабайтах, представляющих собой  собой степени десятки — тех, в которых производители жестких дисков издревле указывают размеры своей продукции. И тогда он определяется таким образом: +1000M, +10G etc.

При задании размера в единицах, отличных от цилиндров, он всегда будет округляться (по обычным правилам округления) до ближайшего числа, кратного целому количеству последних. Так что не следует удивляться, если вместо искомого раздела в 20 Мбайт возникнет 16-мегабайтный, а вместо 22-мегабайтного — раздел в 24 Мбайт.

При создании расширенного раздела сначала все происходит точно также — задание номера (очевидно, что в том же диапазоне 1—4), указание начального цилиндра и конечного (или — объема в мегабайтах). Однако это еще полдела, нужно поделить расширенный раздел на разделы логические. И потому при следующей команде на создание раздела нам будет предложен уже выбор между первичным (если число последних еще не исчерпано) и логическим (ведь второй extended-раздел средствами fdisk создать нельзя):

Command (m for help): n

Command action

   l   logical (5 or over)

   p   primary partition (1-4)

Дальше же логический раздел создается аналогично первичному.

Для каждого вновь создаваемого средствами fdisk раздела (первичного или логического) по умолчанию устанавливается идентификатор типа файловой системы Linux native (83 в шестнадцатеричном исчислении). Расширенный же раздел также автоматически получает правильный идентификатор своего типа — 5. Однако типы эти не есть нечто неизменное. Более того, по крайней мере в одном случае, при создании раздела подкачки, изменение типа раздела — необходимость. Это потребуется также и для использования таких технологий, как Software RAID или LVM, о которых будет говориться позднее.

Делается это командой t, после чего запрашивается номер раздела, тип которого должен быть изменен, а затем — идентификатор желаемого типа. Полный список поддерживаемых типов файловых систем (и их идентификаторов) можно вывести командой l. Напомню, что идентификатор типа файловой системы раздела — отнюдь не файловая система, которая на нем размещается. И на разделе Linux native, как это подчеркивает название, можно создать любую файловую систему из числа тех, которые поддерживаются Linux в качестве родных (ext2/ext3, ext4, XFS, ReiserFS, JFS, btrfs, NILFS2).

Теоретически fdisk позволяет присвоить созданному разделу идентификатор типа почти любой из мыслимых файловых систем — от FAT12 до Free-, Open- и NetBSD. Однако сами по себе файловые системы средствами fdisk не создаются, и потому для разделов любого типа в дальнейшем потребуется их форматирование специальными командами типа mkfs, о которых будет говориться в соответствующей рубрике.

Сказанного, надеюсь, достаточно, чтобы осознать великое достоинство fdisk — исключительную гибкость: можно определить раздел строго определенного размера и точно позиционировать его на диске. Или зарезервировать в любом месте накопителя неразбитое пространство, с двух сторон окруженное созданными разделами.

Сложность же применения fdisk — кажущаяся: благодаря системе подсказки дисковые разделы создаются легко и непринуждённо. Тем не менее, если таки она удручает своей недостаточной наглядностью, можно воспользоваться утилитой cfdisk с меню-ориентированным интерфейсом.

Утилита cfdisk

Как уже говорилось, утилита fdisk часто оказывает устрашающее действие на начинающих пользователей. И потому, идя навстречу их невысказанным пожеланиям, Кевин Мартин (Kevin E. Martin) написал к ней консольный фронт-энд с меню-ориентированным интерфейсом, получивший имя cfdisk.

Утилита cfdisk описывается в литературе гораздо реже, хотя традиционно она считается более удобной, чем fdisk — впрочем, это субъективно и зависит от привычки.

Запустить cfdisk можно одноименной командой, с указанием имени дискового устройства в качестве аргумента:

# cfdisk /dev/sdb

Если аргумент в командной строке опущен — по умолчанию команда будет исполнена для первого физического диска машины.

Разумеется, для использования утилиты требуются права администратора. Если попытаться запустить её от лица обычного пользователя — программа стартует с сообщением. А после запуска программы (в консоли или окне терминала) мы видим следующую картину:

09-disks_193

На ней выводится информация о диске, первом физическом или том, что был указан в качестве аргумента (имя файла устройства, размер, число головок, секторов, цилиндров), таблица существующих разделов (если, кончено, они действительно существуют) и меню из следующих пунктов: Bootable, Delete, Help, Maximize, Print, Quit, Type, Units, Write. Это — для диска с существующими разделами. Если же диск не разбит (или в таблице разделов курсор зафиксирован на неразбитом пространстве), меню ограничивается пунктами Help, New, Print, Quit, Units, Write.

Смысл пунктов, думаю, понятен из их названий, как и возможности программы вообще. Замечу лишь, что здесь, как и в fdisk, до выбора пункта Write (в котором будет запрошено подтверждение действия) никаких необратимых изменений не происходит: через Quit всегда можно покинуть программу без боязни за существующие разделы и данные на них.

И еще: по умолчанию размеры разделов в таблице указаны в тех мегабайтах, к которым мы привыкли — 220 байт, которые, как нынче считается, положено называть мебибайтами. Однако через пункт Units (сиречь единицы измерения) можно переключиться на показ его в секторах или цилиндрах. Для создания раздела выбирается пункт New, выводящий подменю: Primary, Logical, Cancel.

После выбора типа раздела просто задается желаемый его размер (в мегабайтах) и запрашивается, приписать ли раздел к началу диска или его концу. А потом остается только сохранить разбиение в таблице разделов выбором пункта Write (повторяю, с запросом подтверждения, и не просто как y, а вводом полного слова yes — дабы дать дополнительные мгновения на раздумье).

Таким образом, все происходит почти также, как в fdisk. Это и не удивительно: cfdisk по сути лишь интерфейсная для fdisk оболочка. Хотя cfdisk несколько менее гибок: например, раздел в середине неразбитого дискового пространства создать нельзя.

Утилиты форматирования

Утилит для форматирования в Linux существует столько же, сколько и поддерживаемых её ядром файловых систем: чтобы убедиться в этом, достаточно набрать в командной строке mkfs и нажать Enter, что даст примерно такую картину:

mkfs           mkfs.ext2      mkfs.ext4dev   mkfs.minix     mkfs.reiserfs
mkfs.bfs       mkfs.ext3      mkfs.fat       mkfs.msdos     mkfs.vfat
mkfs.cramfs    mkfs.ext4      mkfs.jfs       mkfs.ntfs      mkfs.xfs

И это — оглашение не всего списка: его легко поплнить установкой пакетов поддержки таких файловых систем, как nilfs, f2fs и других, о которых я и не слыхал.

Зато из данного списка становится очевидным, как выполнять форматирование: достаточно дать команду на создание желаемой файловой системы и имя файла устройства (то есть дискового раздела) в качестве её аргумента, например:

$ sudo mkfs.ext4 /dev/sdg1

Как легко догадаться, конечно же, команда даётся от имени root’а. А результатом её работы будет создание на указанном разделе файловой системы ext4fs.

Можно ограничиться и универсальной командой mkfs — но в этом случае, кроме аргумента, потребуется ещё и опция -t с явным указанием файловой системы. Прочие опции всего семейства команд mkfs специфичны для отдельных файловых систем, и говорить о них тут не будем. Как воздержимся и от обсуждения вопроса, какая из файловых систем — самая рассмая и гарантирующая своему применителю счастие немыслимое.

Про графические морды и особенно про GNOME Disks

Как уже говорилось, средств для управления носителями и разделами для них в Linux’ах немало. И если большинство применителей «со стажем» используют в этих целях набор специализированных утилит командной строки, то применители начинающие отдают предпочтение графическим фронт-эндам, интегрирующим функционал всех перечисленных инструментов. Впрочем, последними не брезгуют и те из опытных применителей, кто не одержим фанатизмом и уже переболел детской болезнью крутизны. Среди таких фронт-эндов наибольшую известность и распространение получила программа GParted. Она же применятся обычно во всякого рода Live-дистрибутивах ремонтно-спасательной ориентации, вроде Parted Magic и GParted Live.

Автор этих строк тоже не пренебрегал программой GParted, когда ему требовалось разметить какой-либо носитель на скорую руку (или когда просто лениво было обращаться к инструментам CLI). Однажды, уже в бытность применителем Mint, такая потребность возникла у него в очередной раз. И потому он собрался обратиться к знакомым пистолетам знакомому и привычному фронт-энду. Однако следствие показало, что в Mint 17 таковой в штатном комплекте отсутствует. А вместо него предлагается некий gnome-disks, фигурирующий в разделе Стандартные главного меню Cinnamon’а под простым именем — Диски. Хотя доустановить GParted из репозитория труда бы не составило, я решил опробовать этот инструмент. Ибо до сих пор только слыхал о нём — и не лучшие отзывы. В частности, что в последних его версиях отказались от поддержки softRAID, мотивируя обычным для GNOMEделателей аргументом: Народу это не нужно.

Забегая вперёд, скажу, что опасения по части softRAID оказались не напрасными: в том варианте, в котором gnome-disks присутствует в Mint’е, он позволяет создавать разделы с данным идентификатором — и ничего более. Для дальнейших действий приходится всё равно обращаться к утилите mdadm, но это будет следующим номером нашей программы.

Однако начну по порядку. Запустить gnome-disks можно или через CLI, одноимённой командой, или из меню. Обращаю внимание — в отличие от GParted, пароль пользователя в момент запуска не запрашивается: его спросят только перед выполнением действий, которые на самом деле требуют привилегий администратора.

Будучи запущенным на моём десктопе, gnome-disks показывает следующую картину:

09-disks_194

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

Шестерёнка в правом верхнем углу — вызов главного меню gnome-disks, которое выглядит так:

09-disks_195

Пара сцепленных шестерёнок ниже графика распределения диска по разделам вызывает очень похожее, хотя и не идентичное, меню:

09-disks_196

Смысл всех пунктов обоих меню интуитивно понятен. Следует только учесть, что пункты «верхнего» меню соответствуют манипуляциям над дисками в целом, «нижнего» — над его разделами. Этим и объясняются некоторые различия в этих меню: очевидно, что SMART не имеет смысла для раздела, а изменение параметров монтирования — для диска в целом. Кроме того, пункты, именованные в обоих меню одинаково, выполняют разные действия. Так, Форматирование из «верхнего» меню — ни что иное, как создание таблицы разметки диска (варианты — в стиле MSDOS или GPT):

09-disks_197

А одноимённый пункт из меню «нижнего» — это действительно создание файловой системы на разделе:

09-disks_198

Причём через меню предусмотрен выбор только между FAT, NTFS и Ext4 (в том числе с шифрованием):

09-disks_199

Названия прочих файловых систем следует, выбрав строку Другой, ввести вручную (например, btrfs). Список поддерживаемых файловых систем зависит от установленного в системе инструментария для работы с ними. Например, чтобы отформатировать раздел в JFS, необходимо иметь в установленном виде пакет jfsutils.

Кстати, поле с именем Название — ни что иное, как метка диска.

Думаю, понятно, что оба «форматирования» возможны только на отмонтированных носителях и требуют прав администратора. Причём пароль на доступ к оным запрашивается в самый последний момент, после всех подтверждений серьёзности своих намерений.

Перед этим неплохо бы рассмотреть параметры приводов. В зависимости от типа накопителей, они оказались разными. Так, для SSD информационная панель включала две вкладки — управления питанием

09-disks_200

и включения кеша записи:

09-disks_201

Обе функции по умолчанию отключены. Оно и понятно — для десктопа управление питанием не требуется. А с включением кеширования я решил пока не экспериментировать — ведь речь шла не о тестировании нового накопителя, а о практической работе на реальной машине.

Для традиционного винчестера на 500 ГБ параметры выглядели так:

09-disks_202

09-disks_203

09-disks_204

Вволю поигравшись с функциями gnome-disks и сделав зарубки на счёт того, какие из них мне могут понадобиться в дальнейшем, я приступил к выполнению поставленной боевой задачи — переразметке экспериментального диска /dev/sdc. Каковой выглядел следующим образом:

09-disks_205

Так что первой задачей было удаление некоего «отсебятного» раздела. Для чего, как подсказала мне солдатская смекалка, требовалось нажать кнопку с минусом рядом с кнопкой вызова «нижнего» меню. Что, как и ожидалось, привело к следующему результату:

09-disks_206

Та же солдатская смекалка говорила, что нажатие кнопки с плюсиком приведёт к созданию на пространстве, ставшем неразмеченным, нового раздела, который оставалось только определить как расширенный:

09-disks_207

В результате чего разметка устройства /dev/sdc приобрела такой вид:

09-disks_208

Наличные примерно 300 ГБ расширенного раздела я планировал разметить на 5 примерно равных по объёму разделов логических. Что, с помощью той же самой кнопки Плюс, и проделал для первого, предназначенного в будущем для openSUSE Factory, задав ему для определённости соответствующую метку:

09-disks_209

Далее оставалось проделать ту же процедуру для остальных четырёх логических томов, после чего получилась следующая картина:

09-disks_210

Выбором файловых систем я не заморачивался — он будет сделан при инсталляции целевого дистрибутива. А метки для разделов я присвоил или в соответствие с названиями предполагаемых на них систем, либо просто по именам устройств. Для уже созданных (но не смонтированных) разделов (точнее — файловых систем, ибо label — это её аттрибут) метку можно задать через пункт Изменить файловую систему «нижнего» меню:

09-disks_211

К слову сказать, через предыдущий пункт того же меню, Изменить раздел, можно задать индентификатор его типа:

09-disks_212

Каковых имеется более чем вдоволь:

09-disks_213

Впрочем, из этого изобилия практически значимы лишь менее полудюжины. Да и делать это для разделов, несущих файловые системы, тем более с данными, не очень рекомендуется. Конечно, изменение идентификатора типа к разрушению файловой системы и потере данных не приведёт, проверено на опыте. Но как будут восприниматься идентификаторы, отличные от Linux’ового 0x83 всякими программами работы с дисками — ведомо только Ахурамазде. А самое главное — это нафиг не нужное занятие.

Подведу итоги. Сравнивать GParted напрямую с gnome-disks не возьмусь. Но одно преимущество последней утилиты лежит на поверхности: если GParted запрашивает пароль на доступ к административным правам сразу при запуске, то gnome-disks — только непосредственно перед выполнением операций, для которых они на самом деле требуются. Так, просто поглядеть на схему разметки, параметры носителя и его состояние можно в режиме обычного пользователя. Конечно, это не гарантирует от ошибок, которые в деле разметки дисков могут быть критическими, но несколько снижает их вероятность.

А в целом функционал gnome-disks показался мне вполне достаточным для выполнения всех повседневных практических задач в области работы с дисками, разделами и файловыми системами. И в большинстве обыденных случаев он вполне может заменить комплекс утилит CLI, включая и команду dd для создания образов дисков (кстати, GParted, кажется, делать этого не умеет).  Если, конечно, не требуются какие-то специфические параметры разметки или монтирования — тут специализированные утилиты командной строки вне конкуренции.

Mint и softRAID

Теоретически softRAID Level 0 — самый простой способ объединения двух носителей информации, конкретно дисковых разделов. Однако как раз в Mint оказывается, что задействовать его «искаропки», то есть на стадии инсталляции, не получится. Причина проста до банальности: на установочном носителе любой редакции этого дистрибутива отсутствует пакет mdadm, отвечающий ныне за управление программным RAID. Что, однако, не препятствует подключению его в любой момент времени после установки.

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

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

Для чего, как нетрудно догадаться, требуется установка пакета mdadm, в ходе которого автоматически выполняется сканирование на предмет наличия softRAID’а. И после рестарта машины нужные модули (raid# и всё, что с ними связано) загружаются автоматически, появиляется устройство /dev/md0.

Теперь остаётся определить устройство /dev/md0 на его законное место — я уже несколько лет держу свои рабочие данные на отдельном носителе (разделе, на пуле ZFS или, как в примере, на программном RAID’е), который монтируется в каталог /home/data. Каковой был немедленно создан, и командой chown ему были присвоены атрибуты принадлежности alv:alv (точнее, 1000:1000UID и 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:

09-disks_213a

Или, если не обременять память этим сложным шестнадцатеричным числом, выбрать его из списка, выводимого через пункт Изменить раздел, вызываемый «нижней шестерёнкой»:

09-disks_213b

Дальнейшая работа выполняется с помощью утилиты 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 МБ, но может быть изменён в обе стороны.

Физические тома объединяются в группу томов (VG — Volume group), которая выступает как единое целое и может рассматриваться как логическиий аналог raw-накопителя. И, подобно последнему, делится на разделы — поскольку над физикой мы уже поднялись, они назваются логическими томами (LV — Logical volume). А уж те — опять-таки на «куски», которые, как нетрудно догадаться, носят имя логических экстентов (LE — Logical extent). По размеру логический экстент равен экстенту физическому, которому он ставится в соответствие — однозначно, но одним из двух методов:

  1. линейным (linear mapping), когда логические экстенты последовательно привязываются к физическим сначала первого физического тома, потом второго, и так далее, подобно линейному режиму RAID;
  2. «черезполосным» (striped mapping), при котором «куски» логических экстентов (так называемые блоки чередования, по умолчанию равные 4 КБ) распределяются по физическим экстентам чередующихся физических томов.

Последний метод, сходен с расщеплением данных в RAID Level 0 и, подобно последнему, теоретически способствует быстродействию дисковых операций. При этом очевидно (и важно в контексте дальнейшего развития сюжета), что размер логического тома с чередованием не может быть больше наименьшего из входящих в него томов физических.

В ходе создания собственного хренилища LVM, оказалось, что существует ещё и метод зеркалирования. Надо полагать, что это некое подобие RAID Level 1. Но, поскольку для меня это не актуально, выяснением деталей не занимался.

Вне зависимости от метода соответствия логических и физических экстентов, логические тома предназначены для того, чтобы нести на себе файловые системы, подобно обычным дисковым разделам, причём точно те же самые — любые нативные для Linux’а: ext2/ext3/ext4, XFS, ReiserFS, JFS.

На этом терминологическое введение можно считать законченным — перехожу к описанию действий по организации хренилища данных.

Пакет LVM2, предоставляющий утилиты CLI для работы с логическими томами, устанавливается в Mint по умолчанию. Однако, как говорилось выше, LVM — не тюрьма народов, и не заставляет применителя её зубрить полсотни команд этого пакета (я почти не преувеличиваю — их там 48). Потому что в репозиториях доступна графическая оболочка, интегрирующая все их функции — system-config-lvm. В скобках замечу, что это не просто самая распространённая «морда» к утилитам lvm2, но и единственная активно развиваемая в настоящее время. Так что перво-наперво её следует установить, что я и проделал:

$ apt system-config-lvm

После установки программа под именем Управление логическими томами обнаружилась в секции Администрирование главного меню Cinnamon, откуда и была запущена после ввода пароля, демонстрируя в моём случае такую картину:

09-disks_214

Правда, здесь надо учесть, что перед её запуском я через fdisk установил ID разделов, предназначенных на растерзание LVM, равным 8e. Что в принципе не обязательно — это можно сделать и в графической оболочке, нажав кнопку Инициализировать раздел:

09-disks_215

Однако сам раздел должен быть создан заблаговременно — зафиксировав курсор на неразмеченном пространстве, можно видеть, что кнопка инциализации просто не активна:

09-disks_216

Вне зависимости от того, каким способом были инциализированы разделы, первым шагом после этого будет создание группы томов посредством фиксации одного из инициализированных разделов (я сделал это для самого «жирного») и нажатия кнопки Создать новую:

09-disks_217

В вызываемой её панели достаточно задать какое-либо имя для группы томов, желательно осмысленное, например:

09-disks_218

Впрочем, можно и изменить размер физического экстента в диапазоне от 2 до 1024 МБ — если, конечно, точно знаете, что это нужно (я — так не уверен, поэтому все остальные параметры оставил умолчальными):

09-disks_219

После этого я полюбовался на физический и логический вид группы томов (состоящей пока из одного физического тома, раздела /dev/sda3):

09-disks_220

После чего занялся добавлением в группу физических томов — то есть в моём случае разделов /dev/sdb1 и /dev/sdc1. Для чего просто указывается группа, в которую надо добавить соотвтетсвующее устройство — поскольку группа у меня одна, то и ломать тут голову не над чем:

09-disks_221

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

09-disks_222

Теперь настал черёд поделить эту группу на логические тома. Оно сводится к

  • определению имени тома (опять таки желательно осмысленного — на следующем скриншоте рассмотрен пример тома для текущих проектов);
  • заданию метода соответствия логических экстентов физическим — в примере «чересполосного»;
  • числа «полос» — поскольку в группе томов участвует три устройства, значение его очевидно;
  • размера блока чередования — я сохранил умолчальные 4 килобайта, но его можно увеличить до 512 КБ (опять же не знаю, нужно ли это):

09-disks_223

Затем я задал размер тома и файловую систему для него — в моей системе доступны ext всех видов и XFS:

09-disks_224

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

09-disks_225

Нажав OK, я получил сообщение, что и такой точки не существует и предложение её создать, от которого, разумеется, невозможно отказаться:

09-disks_226

Тем же манеров был создан том для размещения виртуальных машин — как мне объяснили резонные люди, для них быстродействие дисковых операций также важно. На этом лимит томов с чередованием у меня был исчерпан, и оставшееся пространство я разделил на два «линейных» тома — под старые, но периодически нужные проекты, и под всякую всячину типа мультимедии:

09-disks_227

После чего физическая и логическая картины моей группы томов стали выглядеть так:

09-disks_228

Оставалось перезагрузиться (для страховки, можно было заказать и немедленное монтирование томов) и начать заполнять тома данными из бэкапов, разумеется, сделанных до начала не только развлечений с LVM, но и до установки Rebecca.

Mint и ZFS

Соедующая серия очерков посвящена ZFS — универсальной системе размещения данных, интегрирующей в себе собственно файловую систему и технологию управления дисковыми массивами и логическими томами. Если softRAID и LVM посвящено множество сетевых материалов, то тема ZFS в Linux’е (так называемая ZFS on Linux) на русском язые освящена существенно слабее. Поэтому я и решил остановиться на ней подробно.

Общее введение

Одна из главнейших задач при работе на компьютере – манипулирование данными: создание, модификация, копирование, перемещение и так далее. И тут первое – это организация их размещения. Это понятие включает в себя широкий круг частных вопросов – схемы дисковой разметки, управления дисковыми массивами и логическими томами, файловые системы и их монтирование в файловую иерархию. Они тесно связаны между собой, но традиционно решаются каждая с помощью собственного инструментария.

Однако в последние годы в Linux’е получили распространение интегрированные системы размещения данных, объединяющие в себе и файловые системы, и задачи управления массивами и томами, и даже, частично, задачи разметки дисков. Такие системы существовали очень давно – со времен доисторического UNIX’а, но были они проприетарными. ZFS же, разработанная фирмой Sun для своей ОС Solaris, ныне распространяется свободно, под лицензией CDDL. Благодаря чему была портирована на FreeBSD, а в последние годы нативно поддерживается и в Linux’е.

Именно ZFS on Linux и будет героиней нашего романа, и не только в силу своих несравненных достоинств. А во-вторых, развитие проекта ZFS on Linux блестяще демонстрирует торжество инженерного разума над юридической заумью. И потому являет собой просто замечательный литературный сюжет, мимо которого не в силах пройти ни один сочинитель в жанре технологической новеллы. И начать этот сюжет надо издалека.

Дисковая разметка

Говорят, что во времена далекие, теперь почти былинные, файловых систем не было: информация на носители записывалась побитно, без всякой организации в именованные её наборы. Впрочем, такой способ записи данных применялся и много позднее – например, при резервном копировании на стриммерные ленты. Можно обходиться без файловых систем и при записи на стандартные блочные устройства – винчестеры, SSD, компакт-диски.

Однако в большинстве случаев данные на носителях блочного типа организуются в виде файлов, а файлы объединяются в файловые системы – плоские, как в древнем DOS’е, древовидные, как во всех UNIX-подобных операционках, или, так сказать, «многодревные», как в Windows. Каковые могут быть созданы непосредственно на носителе как raw-устройстве, но обычно накладываются на дисковые разделы.

Исторически сложилось так, что одному разделу соответствовала одна файловая система. Соответственно, и выходить за границы несущего их устройства файловые системы не могли. И если требовалось работать более чем с одной файловой системой на одном физическом накопителе (а в UNIX-подобных ОС это почти всегда так), то был необходим тщательный расчет дискового пространства для каждой из них: ошибки в расчетах влекли весьма неприятные последствия, вплоть до необходимости переразбиения диска и переустановки ОС вообще.

Правда, дисковые разделы могут не только разделяться, но и объединяться в программные массивы или в группы томов, о которых говорилось в предыдущих очерках.

Файловые системы

Как известно еще с советских атеистических времен, Господь Бог, создавая человека, хотел сделать его умным, честным и партийным. Но оказалось, что даже он, при всём своём всемогуществе, не смог ему дать больше двух качеств вместе.

Аналогично и с файловыми системами: разработчики хотели бы видеть их быстрыми, надежными и простыми в обращении. Давайте посмотрим, удалось ли им превзойти Господа.

В UNIX-подобных системах требование быстродействия удовлетворяется, во-первых, оптимизированным расположением каталогов, метаданных и данных файлов на физических носителях. Но во-вторых и главных – кэшированием записи.

Думаю, каждого, кто начинал знакомство с Linux’ом во времена безраздельного господства файловой системы ext2fs, поражала быстрота выполнения всех файловых операций, обусловленная их асинхронностью – то есть кэшированием данных и метаданных. Оборотная сторона медали – отказ системы по любой причине влёк за собой тяжкие последствия, вплоть до полного ее разрушения. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) вызывали за собой долгую и нудную процедуру проверки целостности файловой системы.

Были разработаны различные механизмы решения этой проблемы. Однако основным в Linux стало так называемое журналирование, когда сведения о файловых операциях записываются в специальный файл журнала до того, как эти операции будут фактически выполнены. Это дает возможность после любого сбоя «откатить» файловую систему до последнего непротиворечивого состояния. Оборотной стороной чего, как обычно, является снижение быстродействия – различное для отдельных файловых систем и видов файловых операций.

Правда, с точки зрения простоты использования ни в одну из файловых систем Linux’а бросить камень рука не подымется: создание и монтирование их никаких трудностей не сулит. Так что требование «партийности» выполняется, пожалуй, при всех соотношениях «ума» и «честности». Но эта ситуация сохраняется, пока мы не начинаем комбинировать “ум, честность и партийность” файловых систем с аналогичными качествами систем управления RAID’ами или с LVM. В результате чего получаем:

  • либо быстрое и относительно простое решение на основе RAID Level 0, не блещущее надёжностью;
  • либо надёжное решение без ощутимой потери быстродействия на основе одного из RAID с избыточностью, не являющееся, однако, эталоном простоты;
  • либо, наконец, относительно надёжное и потенциально быстрое решение при использовании технологии LVM – однако и оно не блещет простотой.

Ибо все эти решения – многоуровневые. И очевидно, что удлинение «цепочки» уровней в любом случае приводит к снижению надежности: чем больше в ней звеньев, тем вероятней отказ всей цепи.
И тут-то и возникает вопрос: а нельзя ли уменьшить количество уровней, сделать систему более «плоской»? И системы размещения данных, в том числе и ZFS – попытка ответа на него.

Из истории систем размещения

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

Первой из таких предшественниц была, видимо, файловая система Veritas (или VxFS), разработанная фирмой Veritas Software и представленная миру в 1991 году. Она же претендует на звание первой в истории мироздания журналируемой файловой системы. Хотя, насколько мне известно, JFS – эпоним всех журналируемых ФС – в своей реализации для AIX появилась в 1990 году, так что вопрос приоритета остаётся не вполне ясным.

VxFS была основной файловой системой в HP UX, работает также во всех ныне живущих проприетарных UNIX’ах и теоретически может использоваться в Linux’е. Однако о практических примерах последнего я не слышал: VxFS является системой проприетарной и весьма дорогой.

VxFS тесно интегрирована с менеджером логических томов – VxVM. Благодаря чему в ней возможно изменение (в любую сторону) размера файловой системы «на лету», включение различных режимов использования томов – стриппинг данных, их зеркалирование, а также комбинации того и другого, создание избыточных массивов по типу RAID Level 5, изменение внутренней организации данных без остановки работы. Всё это позволяет VxFS (в сочетании с VxVM) претендовать на звание комплексной системы размещения данных.

Впрочем, не меньше к тому оснований было и у AdvFS – файловой системы, разработанной к 1993 году фирмой DEC для своего проприетарного варианта UNIX, именовавшегося сначала OSF/1, затем Digital UNIX, и завершившего свою жизнь под именем Tru64 UNIX. Судьба её была печальной. Снискав заслуженное признание на своей родной платформе DEC Alpha под управлением указанной ОС, она после покупки DEC фирмой Compaq оказалась в загоне. А после того, как Compaq, в свою очередь, был поглощён фирмой Hewlett Packard, использовавшей для своего UNIX’а на платформах HP PA и Itanium только что упомянутую VxFS, AdvFS оказалась совсем не при делах.

В результате HP сделала щедрый дар сообществу свободного софта вообще и Linux-сообществу в особенности: в середине 2008 года исходники файловой системы AdvFS были открыты под лицензией GPv2 – ради максимальной совместимости с ядром Linux. С предложением использовать их в качестве богатой технологической базы для этой ОС. Правда, оговорка, что сама HP не заинтересована в дальнейшем развитии AdvFS заставляла вспомнить народную присказку: «Возьми, боже, что мне не гоже».

Да и предложение несколько запоздало: как мы скоро увидим, к тому времени интенсивно развивались и ZFS, и btrfs.

Однако, помимо исходников, HP предоставила также доступ ко всей документации – благодаря чему об AdvFS при желании можно узнать больше, чем о любой другой проприетарной файловой системе для UNIX-подобных операционок. Это избавляет меня от необходимости описания особенностей AdvFS. Замечу только, что среди них мы увидим все черты развитой комплексной системы размещения данных. Те самые, с которыми ознакомимся, когда дело дойдёт наконец до рассмотрения устройства ZFS. Но для начала перейдём к обзору уже её истории.

Начало истории ZFS

Разработчики ZFS поставили себе честолюбивую цель: создать систему хранения данных, которая отвечала бы всем трем критериям идеала. Разработка её проводилась в компании Sun Microsystems, командой под руководством Джеффа Бонвика и Мэттью Аренса (Matthew Ahrens). Первоначально название ZFS рассматривалось как аббревиатура от Zettabyte File System, но быстро стало просто условным именованием. Его можно интерпретировать как последнюю точку в развитии файловых систем вообще. И в последующем мы увидим: это недалеко от истины.

Результаты работы над ZFS были представлены миру в августе 2004 года. А в 2006 году она была включена в штатный состав OS Solaris 10 (релиз 6/06). То есть, подобно своим предшественницам, она также была проприетарным продуктом. И пользователям свободных UNIX-подобных систем поначалу от ее существования было ни холодно, ни жарко. Однако период камерного существования ZFS продолжался недолго – уже в ноябре 2005 года, то есть до включения в Solaris, ее поддержка была интегрирована в открытый её вариант, OpenSolaris. Ибо она основывалась на том же ядре SunOS 5, что и коммерческий прототип.

Исходники ZFS распространяются, как и собственно OpenSolaris, под лицензией CDDL (Common Development and Distribution License). Эта лицензия, базирующаяся на Mozilla Public License (MPL), не влияет на общую лицензию проекта, в состав который включены CDDL-компоненты. И потому оказывается совместимой с большинством свободных лицензий. За исключением… какой? Правильно, GPL во всех её проявлениях.

Разумеется, ZFS была задействована в клонах openSolaris, таких, как BeleniX, SchilliX и, в первую голову, в Nexenta OS. Правда, последняя развивалась в направлении коммерческой системы хранения данных, а о числе пользователей остальных можно было только гадать.

Некоторое время ZFS была доступна пользователям Macintosh’а – в Mac OS X Leopard от осени 2007 года. Правда, ходившие перед её выходом слухи, что она будет там файловой системой по умолчанию, оказались несколько преувеличенными: поддержка ZFS оказалась опциональной и лишь в режиме «только для чтения». А в последующих версиях семейства кошачьих вообще исчезла и, видимо, уже не возродится.

Так что для широких народных масс ZFS по прежнему оставалась недоступной. Пока… пока ее не портировали под FreeBSD в 2007 году, и официально не включили её поддержку в 7-ю версию этой ОС, вышедшую в начале 2008 года. В чём, как и в дальнейшем её развитии, основная заслуга принадлежит Павлу-Якубу Давидеку (Pawel Jakub Dawidek) и Ивану Ворасу (Ivan Voras). Правда, до недавнего времени ZFS нельзя было задействовать при установке FreeBSD средствами её штатного инсталлятора и конфигуратора sysinstall. Однако это без труда можно было осуществить в дальнейшем руками. В том числе и разместить на ZFS корень файловой иерархии.

С самого начала поддержки ZFS во FreeBSD появилась и возможность задействовать её, что называется, «искаропки», в десктоп-ориентированном клоне последней – PC-BSD. А с переходом FreeBSD, начиная с версии 9.0, на новую программу установки – BSDInstall, эта функция распространилась и на материнскую систему.

Успех ZFS во FreeBSD, где она стала если не главной файловой системой, то добилась равноправия с UFS2, послужил примером для других BSD-систем. Так, ныне ZFS поддерживается в NetBSD – эта работа была начата Оливером Голдом (Oliver Gould) летом 2007 года в рамках акции Google Summer of Code. А в 2009 году Адам Хамсик (Adam Hamsik) интегрировал её код в ядро NetBSD. Правда, использование ZFS в этой операционке рекомендуется только в экспериментальных целях.

Наконец, одно время в списках рассылки DragonFlyBSD активно обсуждался вопрос о портировании ZFS и на эту операционку. Потом, правда, разговоры эти стихли – вероятно, в связи с активной разработкой файловой системы Hammer, обладающей во многом аналогичными возможностями. Однако, учитывая лёгкость адаптации к DragonFlyBSD любых сторонних файловых систем, можно не сомневаться, что поддержка ZFS на уровне обмена данными будет включена в неё тогда и если (или если и тогда), когда (и если) это кому-то понадобится.

Таким образом, пользователям большинства BSD-систем ZFS или уже доступна как нативная, или может стать доступной в ближайшее время.

Из истории юриспруденции

А что же Linux, спросите вы меня? Как обстоит дело с поддержкой ZFS в самой массовой из свободных UNIX-подобных операционных систем нашего времени? А вот с Linux’ом все оказывается гораздо сложнее. Ибо не зря поминали мы выше лицензию CDDL. Которая сама по себе очень даже свободная, и не накладывает почти никаких ограничений на распространение защищаемых ею программ.

В частности, не запрещает CDDL и коммерческого распространения производных продуктов в виде бинарников, без открытия исходных текстов. Как известно, не накладывает такого ограничения и лицензия BSD, почему включение кода поддержки ZFS в любые BSD-системы и проходит юридически безболезненно, как мы только что видели на примере FreeBSD.

А вот с лицензией GPL обеих актуальных версий (v2 и v3) CDDL входит в диалектическое противоречие. Ибо любые продукты, производные от программ под GPL, вне зависимости от формы распространения, должны сопровождаться исходными текстами. Что делает юридически невозможным включение кода поддержки ZFS непосредственно в ядро Linux, распространяемое, как известно, на условиях GPLv2.

Кроме того, невозможность включения в ядро Linux кода поддержки ZFS объясняется тем, что GPL требует распространения всех основанных на ней продуктов под GPL же, тогда как CDDL – сохранения её для «своих» компонентов.

Правда, часть кода ZFS была открыта под GPL с тем, чтобы соответствующий патч можно было включить в загрузчик GRUB. Это обеспечило возможность загрузки Open Solaris непосредственно с ZFS-раздела. Однако оказалось недостаточным для полноценной реализации этой системы, которую можно было бы распространять под данной лицензией.

Впрочем, не будучи юристом, ломать голову над лицензионными вопросами не буду, и моим читателям не советую, ибо понять это всё равно невозможно. А достаточно лишь запомнить, что всеми резонными и юридически подкованными людьми признано, что поддержки ZFS в ядре Linux быть не может.

Таким образом, сложилась абсурдная, с точки зрения здравого смысла, ситуация: два программных продукта под свободными лицензиями (обсуждать вопрос, какая из них «свободней другой», мы сейчас не будем), созданные друг для друга, как Huggies и… э-ээ… место пониже спины (дальнейшие события показали, что технических сложностей при портировании ZFS на Linux практически нет), невозможно было использовать в составе одного проекта. По крайней мере, для законопослушных граждан, чтущих… нет, не уголовный кодекс, а принципы свободного программного обеспечения.

И, разумеется, здравомыслящие люди попытались эту ситуацию разрешить. И первая такая попытка была предпринята ещё в 2006 году в рамках Google Summer of Code. Основывалась она на поддержке ZFS через FUSE (Filesystem in Userspace). Поскольку модуль FUSE работает как пользовательское приложение, необходимости во включение кода ZFS в ядро Linux нет, что снимает все юридические вопросы. Однако встают вопросы другие – производительности и устойчивости.

Проект ZFS-FUSE развивается по сей день, хотя и не очень быстрыми темпами. Правда, находясь в стадии хронической бета-версии, он до сих пор рассматривается как сугубо экспериментальный. Да и в любом случае в таком виде ZFS выполнять свои функции – быть надёжным хранилищем данных большого объёма – скорее всего, не сможет.
Так что ZFS-FUSE нельзя считать кардинальным решением вопроса с этой системой размещения данных в Linux.

Появление героини

И тем не менее, решение этой проблемы нашлось – и решение столь же изящное, сколь и очевидное. Его предложил весной 2010 года Брайан Белендорф, некогда один из основных разработчиков web-сервера Apache. Он создал модуль поддержки ZFS, который собирается и может распространяться отдельно от ядра, сохраняя прародительскую лицензию CDDL. А поскольку последняя, как уже говорилось, является лицензией «пофайловой», этим самым обходится антагонистическое противоречие – запрет на распространение продуктов, в которых смешан код, лицензируемый под CDDL и GPL.

На базе разработки Брайана возникло сразу два проекта. Первый осуществлялся индийской компанией KQ Infotech, которой уже в сентябре 2010 года удалось выпустить работоспособный, пригодный для тестирования Linux-ядра с реализацией файловой системы ZFS. А в январе следующего, 2011, года появилась финальная его версия, доступная тогда в исходниках и в виде двоичных пакетов для Fedora 14, RHEL6, Ubuntu 10.04 и 10.10.

Однако весной того же года KQ Infotech была куплена фирмой STEC, занимающейся производством SSD-накопителей, каковых, впрочем, в наших палестинах мало кто видел. И работы по дальнейшему развитию нативной поддержки ZFS были свёрнуты. Хотя исходники модуля и сопутствующих компонентов до сих пор доступны, последнее их обновление происходило более года назад. А информации о дальнейшей судьбе проекта с тех пор не появлялось.

Второй проект реализовывался самим Брайном вместе с сотрудниками Ливерморской национальной лаборатории, каковая, будучи в подчинении Министерства энергетики США, занимается не только вопросами ядерного оружия (эвфемизмы вроде Минсредмаша в ходу не только в бывшем Советском Союзе), но и разработкой суперкомьютеров. В результате скоро возник проект ZFS on Linux – ZFS on Linux, в рамках которого модуль поддержки ZFS и сопутствующие утилиты поддержки, портированные из Solaris – так называемый SPL (Solaris Porting Layer), были доведены до ума, и к началу 2011 года стали пригодны для использования в экспериментальном режиме. А к настоящему времени, несмотря на формальное сохранение статуса release candidatе, порт ZFS on Linux можно считать готовым к практическому применению.

Правда, майнтайнеры основных дистрибутивов не торопились включать поддержку ZFS в свои системы даже в качестве дополнительных неофициальных пакетов. Подозреваю, что не столько из косности и лени, сколько из-за очередной сложности: видимо, по всё тем же лицензионным ограничениям модули zfs и spl приходится привязывать к фиксированной версии (и даже конкретной сборке) ядра Linux. Что, при регулярных, даже корректирующих, обновлениях последнего требует и их пересборки.

Тем не менее, разработчики проекта воплотили результаты своей работы в виде PPA-репозитория для Ubuntu. Каковым без проблем могут пользоваться и применители Mint.

Обзор возможностей

Прежде чем погружаться в вопросы, связанные с ZFS, читатель, вероятно, хотел бы убедиться в том, что это стоит делать. То есть – ознакомиться с возможностями, которые она ему предоставляет.

Для начала – немного цифр. В отличие от всех предшествовавших файловых систем и систем размещения данных, ZFS является 128-битной. То есть теоретическое ограничение на её объём и объёмы её составляющих превышают не только реальные, но и воображаемые потребности любого пользователя. По выражению создателя ZFS, Джеффа Бонвика, для её заполнения данными и их хранения потребовалось бы вскипятить океан.

Так, объём пула хранения данных (zpool – максимальная единица в системе ZFS) может достигать величины 3×1023 петабайт (а один петабайт, напомню, это 1015 или 250 байт, в зависимости от системы измерения). Каждый пул может включать в себя до 264 устройств (например, дисков), а всего пулов в одной системе может быть тоже не больше 264.

Пул может быть разделён на 264 наборов данных (dataset – в этом качестве выступают, например, отдельные файловые системы), по 264 каждая. Правда, ни одна из таких файловых систем не может содержать больше 248 файлов. Зато размер любого файла ограничивается опять же значением в 264 байт.

Количество таких ограничений можно умножить. Как уже было сказано, они лежат вне пределов человеческого воображения. И привожу я их только для того, чтобы вселить в пользователя уверенность: ни он сам, ни его внуки и правнуки в реальности не столкнутся c ограничениями на размер файловой системы или отдельного файла, как это бывало при использовании FAT или ext2fs.

Так что перейду к особенностям ZFS, наиболее интересным, по моему мнению, десктопному пользователю. Здесь в первую очередь надо отметить гибкое управление устройствами. В пул хранения данных можно объединить произвольное (в обозначенных выше пределах) число дисков и их разделов. Устройства внутри пула могут работать в режиме расщепления данных, зеркалирования или избыточности с подсчётом контрольных сумм, подобно RAID’ам уровней 0, 1 и 5, соответственно. В пул можно включать накопители, специально предназначенные для кэширования дисковых операций, что актуально при совместном использовании SSD и традиционных винчестеров.

Пул хранения становится доступным для работы сразу после его создания, без рестарта машины. В процессе работы дополнительные диски или разделы, в том числе и устройства кэширования, могут как присоединяться к пулу, так и изыматься из его состава в «горячем» режиме.

Пул хранения может быть разделён на произвольное количество иерархически организованных файловых систем. По умолчанию размер их не определяется, и растёт по мере заполнения данными. Это избавляет пользователя от необходимости расчёта места, потребного под системные журналы, домашние каталоги пользователей и другие трудно прогнозируемые вещи. С другой стороны, не запрещено при необходимости и квотирование объёма отдельных файловых систем – например, домашних каталогов отдельных излишне жадных пользователей.

Файловые системы ZFS также доступны для размещения на них данных сразу после создания, никаких специальных действий по обеспечению их монтирования не требуется. Создание файловых систем внутри пула – процесс предельно простой: разработчики стремились сделать его не сложнее создания каталогов, и это им вполне удалось. Но при этом составляющие пула остаются именно самостоятельными файловыми системами, которые могут монтироваться со своими специфическими опциями, в зависимости от назначения.

Среди других возможностей ZFS, интересных настольному пользователю, можно упомянуть:

  • создание снапшотов файловой системы, позволяющих восстановить её состояние в случае ошибки;
  • клонирование файловых систем;
  • компрессия данных файловой системы и дедупликация (замена повторяющихся данных ссылками на «первоисточник»);
  • создание нескольких копий блоков с критически важными данными и, напротив, возможность отключения проверки контрольных сумм для повышения скорости доступа к ним.

В общем, даже если не говорить об быстродействии ZFS (а оно весьма высоко, особенно в многодисковых конфигурациях), перечислять её достоинства можно очень долго. Так долго, что поневоле успеваешь задаться вопросом: а есть ли у неё недостатки?

Разумеется, есть. Хотя большая их часть – скорее особенности: например, ограничения при добавлении или удалении накопителей в пуле, или отсутствие поддежки TRIM.

По большому счёту для пользователя Linux’а у ZFS обнаруживается два кардинальных недостатка: некоторая усложнённость её использования, обусловленная юридическими факторами, и высокие требования к аппаратуре.

Первый недостаток если не ликвидирован, то сглажен трудами Брайана Белендорфа (Brian Behlendorf) со товарищи и майнтайнерами прогрессивных дистрибутивов вкупе с примкнувшими к ним независимыми разработчиками. Аппаратные же претензии ZFS мы сейчас и рассмотрим.

Аппаратные потребности

Итак, ZFS предоставляет пользователю весьма много возможностей. И потому вправе предъявлять немало претензий к аппаратной части – процессору (изобилие возможностей ZFS создает на него достаточную нагрузку), оперативной памяти и дисковой подсистеме.

Впрочем, претензии эти отнюдь не сверхъестественные. Так, процессор подойдёт любой из относительно современных, начиная, скажем, с Core 2 Duo. Минимальный объём памяти определяется в 2 ГБ, с оговоркой, что применение компрессии и дедупликации требуют 8 ГБ и более.

Сама по себе ZFS прекрасно функционирует и на одиночном диске. Однако в полном блеске показывает себя при двух и более накопителях. В многодисковых конфигурациях рекомендуется разнесение накопителей на разные контроллеры: современные SSD способны полностью загрузить все каналы SATA-III, и равномерное распределение нагрузки на пару контроллеров может увеличить быстродействие.

К «железным» претензиям добавляются и притязания программные. В первую очередь, ZFS on Linux требует 64-битной сборки этой ОС, поскольку в 32-разрядных системах действует ограничение на адресное пространство физической памяти. Кроме того, в конфигурации ядра должнв быть отключена опция CONFIG_PREEMPT.

Если вас привлекли достоинства ZFS и не устрашили её «железные» аппетиты, самое время опробовать её в деле. Что потребует знакомства с некоторыми специфическими понятиями.

Терминология

Центральным понятием ZFS является пул хранения данных (zpool). В него может объединяться несколько физических устройств хранения – дисков или дисковых разделов, причём первый вариант рекомендуется. Но не запрещено и создание пула из одного диска или его раздела.

Каждый пул состоит из одного или нескольких виртуальных устройств (vdev). В качестве таковых могут выступать устройства без избыточности (то есть всё те же диски и/или их разделы), или устройства с избыточностью – зеркала и массивы типа RAID-Z:

Зеркальное устройство (mirror) – виртуальное устройство, хранящее на двух или более физических устройствах, но при чётном их количестве, идентичные копии данных на случай отказа диска;

RAID-Z – виртуальное устройство из нескольких устройств физических, предназначенное для хранения данных и их контрольных сумм с однократным или двойным контролем чётности. В первом случае теоретически требуется не менее двух, во втором – не менее трёх физических устройств.

Если пул образован устройствами без избыточности (просто дисками или разделами), то одно из vdev, соответствующее ему целиком, выступает в качестве корневого устройства. Пул из устройств с избыточностью может содержать более одного корневого устройства – например, два зеркала.

Пулы, образованные виртуальными устройствами, служат вместилищем для наборов данных (dataset). Они бывают следующих видов:

  • файловая система (filesystem) – набор данных, смонтированный в определённой точке и ведущий себя подобно любой другой файловой системе;
  • снапшот (snapshot) – моментальный снимок текущего состояния файловой системы, доступный только для чтения;
  • клон (clone) – точная копия файловой системы в момент его создания; создаётся на основе снимка, но, в отличие от него, доступен для записи;
  • том (volume) – набор данных, эмулирующий физическое устройство, например, раздел подкачки.

Наборы данных пула должны носить уникальные имена такого вида:
pool_name/path/(dataset_name)(@snapshot_name)

Пулы и наборы данных в именуются по правилам пространства имён ZFS, впрочем, довольно простым. Запрещёнными символами для всех являются символы подчёркивания, дефиса, двоеточия, точки и процента. Имя пула при этом обязательно должно начинаться с алфавитного символа и не совпадать с одним из зарезервированных имён – log, mirror, raidz или spare (последнее обозначает имя устройства «горячего» резерва). Все остальные имена, в соответствие с демократическими традициями пространства имён ZFS, разрешены.

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

Модели именования устройств

В современном 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 в Mint

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

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

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

09-disks_229

Для использования 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

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

pool: data
state: ONLINE
scan: none requested
config:

NAME        STATE     READ WRITE CKSUM
mypool      ONLINE       0     0     0
sdd       ONLINE       0     0     0
sdf       ONLINE       0     0     0

errors: No known data errors

А с помощью субкоманды list можно узнать объём новообразованного пула:

# zpool list data
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
data  18,9G    93K  18,9G     0%  1.00x  ONLINE  -

Легко видеть, что он равен сумме объёмов обеих флэшек, если «маркетинговые» гигабайты пересчитать в «настоящие».

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

# zpool list
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
exp   18,9G    93K  18,9G     0%  1.00x  ONLINE  -
data  199G  20,8G   178G    10%  1.00x  ONLINE  -

Обращаю внимание, что даже чисто информационные субкоманды вроде list и status требуют прав администратора.

Разумеется, два пула в одной, да ещё и настольной, машине – излишняя роскошь. Так что пул, созданный в экспериментальных целях, подлежит уничтожению, что делается с помощью субкоманды destroy:

# zpool destroy exp

После чего он пропадёт из списка пулов. А что можно сделать с пулом до его уничтожения, увидим со временем.

«Избыточные» пулы

Избавившись от ставшего ненужным пула, рассмотрим второй вариант – создание пула с зеркальным устройством. Создаём его из двух накопителей одинакового объёма:

# zpool create -f exp2 mirror sdf sdg

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

# zpool list mypool
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
exp2  3,72G  91,5K  3,72G     0%  1.00x  ONLINE  -

При различии объёмов больший диск будет «обрезан» до объёма меньшего.

Полное зеркалирование любыми, по моему мнению, в настольных условиях – роскошь непозволительная: банальные бэкапы данных проще и надёжнее. Тем не менее, не исключаю, что некоторая избыточность на уровне проверки контрольных сумм может оказаться не лишней, да и не столь накладна. Так что давайте посмотрим и на третий вариант пула из более чем одного устройства – RAID-Z.

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

# zpool create exp3 raidz sdd sdf sdg

что даст нам следующую картину:

# zpool list exp3
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
exp3  11,1G   205K  11,1G     0%  1.00x  ONLINE  -

Впрочем, как мне кажется, в настольных условиях не стоит выделки и эта овчинка.

Пул кэшируемый

И, наконец, последний вариант организации пула из более чем одного устройства – создание пула с кэшированием. Для чего создаём из двух устройств простой пул без избыточности и подсоединяем к нему устройство для кэша:

# zpool create exp4 sdd sdf cache sdg

Очевидно, что устройство для кэширования не должно входить в пул любого рода – ни в простой, ни в избыточный. Что мы и видим в выводе субкоманды list:

# zpool list exp4
NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
exp4  18,9G    82K  18,9G     0%  1.00x  ONLINE  -

где никаких следов его обнаружить не удаётся. Если же появляются сомнения, а подключилось ли оно на самом деле, обращаемся к субкоманде status, которая покажет беспочвенность наших опасений.

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

О некоторых опциях команды zpool

Команда zpool поддерживает ещё множество субкоманд, предназначенных для экспорта и импорта пула, добавления к нему устройств и изъятия оных, и так далее. Но сейчас я расскажу о некоторых опциях, которые могут оказаться необходимыми при создании пула.

Одна из важный опций – -f: она предписывает принудительное выполнение данной операции и требуется, например, при создании пула из неразмеченных устройств.

Полезной может оказаться опция -n. Она определяет тестовый режим выполнения определённой субкоманды, то есть выводит результат, например, субкоманды zpool create без фактического создания пула. И, соответственно, сообщает об ошибках, если таковые имеются.

Интересна также опция -m mountpoint. Как уже говорилось, при создании пула по умолчанию в корне файловой иерархии создаётся каталог /pool_name, который в дальнейшем будет точкой монтирования файловых систем ZFS. Возможно, что это окажется не самым лучшим местом для их размещения, и, как мы увидим в дальнейшем, это несложно будет изменить. Но можно задать каталог для пула сразу – например, /home/data: это и будет значением опции -m. Никто не запрещает определить в качестве такового и какой-либо из существующих каталогов, если он пуст, иначе автоматическое монтирование файловых систем пула в него окажется невозможным.

Наконец, нынче важное значение приобретает опция ashift=#, значением которой является размер блока файловой системы в виде степеней двойки. По умолчанию при создании пула размер блока определяется автоматически, и до некоторого времени это было оптимально. Однако затем, с одной стороны, появились диски так называемого Advanced Format, в других размер блока равен 4 КБ. С другой стороны, получили распространение SSD-накопители, обычно также имеющие четырёхкилобайтный блок. В этих условиях автоматика ZFS может работать некорректно, что приводит к падению производительности пула.

Для предотвращения означенного безобразия и была придумана опция ashift. Значение её по умолчанию – 0, что соответствует автоматическому определению размера блока. Прочие же возможные значения лежат в диапазоне от 9 для блока в 512 байт (29 = 512) до 16 для 64-килобайтного блока (216 = 65536). В интересующем нас случае четырёхкилобайтного блока оно составляет 12 (212 = 4096). Именно последнее значение и следует указать явным образом при создании пула из винчестеров AF или большинства SSD-накопителей.

Создание файловых систем

Пулы хранения представляют собой вместилища для наборов данных, для манипуляции которыми предназначена вторая из главнейших команд – zfs. Самыми важными наборами данных являются файловые системы, к рассмотрению которых мы и переходим.

Для создания файловых систем предназначена субкоманда create команды zfs, которая требует единственного аргумента – имени создаваемой ФС и обычно не нуждается ни в каких опциях:
# zfs create pool_name/fs_name

Внутри пула можно создавать сколь угодно сложную иерархию файловых систем. Единственное условие – родительская файловая система для системы более глубокого уровня вложенности должна быть создана заблаговременно. Ниже я покажу это на конкретном примере создания файловых систем внутри каталога /home – наиболее оправданное место для размещения наборов данных ZFS.

Начну я немножечко издалека. При стандартной установке Mint не обойтись без создания учетной записи обычного пользователя, и, следовательно, в каталоге /home будет присутствовать по крайней мере один подкаталог – /home/username.

Смонтировать же файловую систему ZFS в непустой каталог невозможно, и, значит, мы не можем сразу прибегнуть к опции -m для определения «постоянной прописки» создаваемого пула.

Поэтому для начала делаем для пула «прописку» во временной точке – пусть это будет традиционный /tank:

# zpool create -o ashift=12 tank ata-SanDisk_SDSSDX120GG25_120823400863-part3 ata-SanDisk_SDSSDX120GG25_120823402786-part3

Теперь создаём файловую систему для будущего домашнего каталога:

# zfs create tank/home

А внутри же неё – необходимые дочерние ветви, как то:

# zfs create tank/home/alv

которая потом заменит мой домашний каталог – в нём я не держу ничего, кроме конфигурационных файлов;
# zfs create tank/home/proj

это файловая система для моих текущих проектов, и так далее.

Как и было обещано разработчиками ZFS, процедура ничуть не сложнее, чем создание обычных каталогов. Благодаря этому файловые системы можно легко создавать по мере надобности, для решения какой-либо частной задачи. И столь же легко уничтожать их, когда задача эта выполнена. Что делается таким образом:

# zfs destroy pool_name/fs_name

Использовать субкоманду destroy следует аккуратно: никакого запроса на подтверждение при этом не будет. Правда, и уничтожить файловую систему, занятую в каком-либо текущем процессе, можно только с указанием опции -f, а файловую систему, содержащую системы дочерние, не получится убить и таким образом.

Ни в какой специальной операции монтирования новообразованные файловые системы не нуждаются – оно происходит автоматически в момент их создания, о чём свидетельствует следующая команда:
$ mount | grep tank tank/home on /tank/home type zfs (rw,atime,xattr) tank/home/alv on /tank/home/alv type zfs (rw,atime,xattr) tank/home/proj on /tank/home/proj type zfs (rw,atime,xattr) …

Для обеспечения монтирования файловых систем 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, о которой мы сейчас разговариваем, это не относится.

Оглавление

Linux Mint и его Cinnamon. Очерки применителя. Часть 10: 5 комментариев

  1. Мне показалось, или в описании GPT есть повтор?
    А так — очень интересно и познавательно (впрочем как всегда).

  2. В том варианте, в котором gnome-disks присутствует в Mint’е, он таки позволяет создавать RAID`ы, просто оно несколько, гм-м-м-м, спрятано. Если нажать на кнопочку с галочкой над списком устройств, а после выделить в списке галочками то, из чего будет лепиться массив, то вот тогда появится кнопка, которая запускает процедуру создания массива.

  3. Спасибо, буду знать. Хотя сам пользуюсь mdadm, честно говоря :)
    Кстати, а ведь в стандартной инсталляции mdadm нет, его наверное надо установить? Ведь без него и три GNOME Disk не смогут создать RAID.

  4. Кстати да, mdadm в дефолте не стоит. Гномодиск — оболочка, которая только и того, что запускает командную строку даже не зная сработает ли оно. Но удобно: и образ монтирует, и разделы создает, рейды клеит, и еще чего-то там…

Оставить комментарий

Перейти к верхней панели