Mint и LVM. Часть 1, вводная

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

Эта история началась с того, что в силу стечения ряда обстоятельств я стал счастливым обладателем SSD-накопителя производства Crucial MX100 объёмом 512 ГБ. От описания его особенностей воздержусть — эта линейка моделей (от 128 ГБ до указанной выше цифры), ввиду сочетания «брендовости», вышесредних скоростных показателей и гуманной цены, сейчас, что называется, на слуху, и на любом «железячном» сайте можно найти её обзоры и тесты. Для дальнейшего сюжета важно, что в результате дисковая подсистема, упакованная внутри моего десктопа, стала выглядеть так:

  • вышеупомянутый полутерабайтный Crucial — на первом SATA-разъёме;
  • SanDisk Extreme SSD, 120 Гбайт — на втором;
  • он же, то есть точно такой же — на третьем;
  • традиционный винчестер Seagate ST3500410AS о 500-х гигабайтах — на четвёртом.

Поскольку «мама» моя на чипсете H77, только первые два SSD-накопителя могут пользоваться всеми прелестями интерфейса SATA-III, третьему же с приходом «жирного» родственника пришлось сесть на зауженный канал. Что, впрочем, легко улавливается на тестах, но с трудом — на реальных задачах: в любом случае любой SSD будет очень ощутимо быстрее механического винчестера. Тем не менее, хотелось подойти к этому вопросу вдумчиво и распорядиться наличными хренилищами рационально.

Впрочем, вру: поначалу хотелось поскорей водрузить на Crucial MX100 систему и записать рабочие данные. Согласитесь, ведь ещё совсем недавно SSD в десять раз меньшего объёма казался трудно достижимой мечтой. Так что, думаю, желание поглядеть на это чудо в деле понятно. Однако, как обычно, нетерпение привело к тому, что объект его, сиречь MX100, был размечен по весьма неудачной схеме, а оба SanDisk’а вообще оказались не при делах. И потому я ждал только повода для полной переустановки системы на полностью перекомпонованные носители.

Поводом этим послужил выход кандидата в релизы Mint 17.1, она же Rebecca — и процесс её установки пошёл сразу по скачивании образа, о чём было отрапортовано своевременно.

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

  • /dev/sda1 объёмом 20 ГБ с файловой системой ext4 под корень файловой иерархии;
  • /dev/sda2 объёмом 10 ГБ, также с ext4 — под каталог будущего пользователя, то есть меня — /home/alv (в домашнем каталоге я храню только dot-файлы и некоторые служебные данные, на что указанного объёма хватало с лихвой);
  • /dev/sda3 на всё оставшееся пространство — без файловой системы и, сооветственно, без точки монтирования.

На обоих SanDisk’ах было создано по разделу, занимающему их целиком (/dev/sdb1 и /dev/sdc1, соответственно), также без файловой системы. Вместе с /dev/sda3 они предназначались для объединения в хренилище моих рабочих данных — организация оного и является предметом данных очерков.

Винчестер у меня служит для экспериментальных целей, и потому разметка его постоянно меняется, да и к нашей теме не относится. За исключением того, что первые 16 ГБ диска выделены в раздел/dev/sdd1, служащий swap’ом для всех моих систем.

Очевидно, что организация хренилища из трёх устройств требовала их объединения тем или иным способом, каковых приходило на ум четыре:

  1. программный RAID в «линейном» режиме;
  2. том btrfs с её субтомами (subvolumes);
  3. пул ZFS с её наборами данных (datasets);
  4. технология LVM (Logical Volume Manager).

Линейный RAID сразу был отметён с негодованием как лишённый в данной ситуации смысла (и вообще плохо применимый к SSD-накопителям, не любящим полного заполнения). Вариант с btrfs я тоже всеръёз не рассматривал, что бы ни говорили о готовности этой системы к промышленному использованию. Характерно, что в openSUSE, кажется, первой взявшей её на вооружение как умолчальной, btrfs задействуется под корневую файловую систему, тогда как бесценные пользовательские данные по умолчанию предлагается размещать на XFS.

Выбор 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.

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

Часть 2

Mint и LVM. Часть 1, вводная: 3 комментария

  1. А что такое «хрЕнилище» ? Может — хранилище ?

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

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