Алексей Федорчук - Linux Mint и его Cinnamon. Очерки применителя

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

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

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

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

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

• определению имени тома (опять таки желательно осмысленного — на следующем скриншоте рассмотрен пример тома для текущих проектов);

• заданию метода соответствия логических экстентов физическим — в примере «чересполосного»;

• числа «полос» — поскольку в группе томов участвует три устройства, значение его очевидно;

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

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

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

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

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

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

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

Соедующая серия очерков посвящена 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, поражала быстрота выполнения всех файловых операций, обусловленная их асинхронностью — то есть кэшированием данных и метаданных. Оборотная сторона медали — отказ системы по любой причине влёк за собой тяжкие последствия, вплоть до полного ее разрушения. Но и даже когда до полной катастрофы дело не доходило, отказы (например, по питанию) вызывали за собой долгую и нудную процедуру проверки целостности файловой системы.