LVM
Mint и LVM.
Эта история началась с того, что в силу стечения ряда обстоятельств я стал счастливым обладателем SSD-накопителя производства Crucial MX100 объёмом 512 ГБ. От описания его особенностей воздержусть — эта линейка моделей (от 128 ГБ до указанной выше цифры), ввиду сочетания «брендовости», вышесредних скоростных показателей и гуманной цены, сейчас, что называется, на слуху, и на любом «железячном» сайте можно найти её обзоры и тесты. Для дальнейшего сюжета важно, что в результате дисковая подсистема, упакованная внутри моего десктопа, стала выглядеть так:
Впрочем, вру: поначалу хотелось поскорей водрузить на Crucial MX100 систему и записать рабочие данные. Согласитесь, ведь ещё совсем недавно SSD в десять раз меньшего объёма казался трудно достижимой мечтой. Так что, думаю, желание поглядеть на это чудо в деле понятно. Однако, как обычно, нетерпение привело к тому, что объект его, сиречь MX100, был размечен по весьма неудачной схеме, а оба SanDisk’а вообще оказались не при делах. И потому я ждал только повода для полной переустановки системы на полностью перекомпонованные носители.
Поводом этим послужил выход кандидата в релизы Mint 17.1, она же Rebecca — и процесс её установки пошёл сразу по скачивании образа, о чём было отрапортовано своевременно.
Описывать процесс установки не буду — он ничем не изменился с прежних времён. В рамках нынешнего сюжета важна только дисковая разметка при инсталляции, каковая, естественно, проводилась на MX100 (файл устройства
Винчестер у меня служит для экспериментальных целей, и потому разметка его постоянно меняется, да и к нашей теме не относится. За исключением того, что первые 16 ГБ диска выделены в раздел
Очевидно, что организация хренилища из трёх устройств требовала их объединения тем или иным способом, каковых приходило на ум четыре:
Выбор ZFS, казалось бы, напрашивался: эту систему хранения данных я люблю, более-менее знаю, даже кое-чего про неё сочинил (например, это), и включал её поддержку в сборки своих вариантов Mint 17. Однако тут модули ZFS у меня неожиданно с первого раза не собрались. Правда, проблема решилась (благодаря помощи Станислава Шрамко aka stanis, о чём в другой раз), однако, как говорится, осадок остался. Ибо случай этот послужил напоминанием не только о бренности бытия, но и птичьих правах, на которых существует ZFS on Linux.
В своё время, более десяти лет назад, я очень увлекался технологией LVM, тогда ещё 1-й версии, и даже сочинил про неё довольно подробную статью. Потом я это дело забросил по двум причинам. Во-первых, во времена винчестеров с PATA-интерфейсом было очень сложно сконфигурировать многодисковую систему LVM без деградации производительности. Во-вторых, инструментарий CLI для создания такой системы и последующего управления ею показался мне при использовании в «домашних» условиях неоправданно сложным — особенно в сравнении с появившейся вскоре ZFS.
Ныне, в эпозу безраздельного господства SATA-накопителей, первое препятствие к применению LVM отпало полностью. Что касается второго, то оно во многом сглаживается наличием графических оболочек, изолирующих применителя от низкоуровневых команд. Одну из которых
С тех пор, как я имел дело с LVM, появилась LVM2, предоставляющая ряд дополнительных возможностей, таких, как расширение логического тома на вновь подключённые физические тома. Однако суть технологии, терминология, утилиты CLI для работы с LVM почти не изменились. Да и в сети можно найти много не менее подробных, но более свежих материалов по теме (пожалуй, вот наиболее полный). Так что на этих вопросах останавливаться не буду, ограничившись маленьким терминологическим конспектом.
Сама по себе система LVM — уровень абстракции между физическими носителями (дисками, их разделами и массивами) и обычными файловыми системами. Она позволяет объединять в логические тома разделы с разных дисков, изменять их размер в сторону увеличения (за счёт присоединения новых накопителей) и, с некоторыми оговорками, уменьшения. В основе её лежит понятие физического тома (PV — Physical volume). Это — обычный дисковый раздел, для которого устанавливается идентификатор типа (ID)
Физический том делится на «куски», именуемые физическими экстентами (Physical Extent, PE — по традиции олставлю этот термин без перевода, так как предлагаемый русскоязычной Википедией диапазон может ввести в заблуждение). Это — нечто вроде аналогов физических блоков (секторов) обычного винчестера, их размер по умолчанию 4 МБ, но может быть изменён в обе стороны.
Физические тома объединяются в группу томов (VG — Volume group), которая выступает как единое целое и может рассматриваться как логическиий аналог raw-накопителя. И, подобно последнему, делится на разделы — поскольку над физикой мы уже поднялись, они назваются логическими томами (LV — Logical volume). А уж те — опять-таки на «куски», которые, как нетрудно догадаться, носят имя логических экстентов (LE — Logical extent). По размеру логический экстент равен экстенту физическому, которому он ставится в соответствие — однозначно, но одним из двух методов:
В ходе создания собственного хренилища LVM, описанного на следующей странице, оказалось, что существует ещё и метод зеркалирования. Надо полагать, что это некое подобие RAID Level 1. Но, поскольку для меня это не актуально, выяснением деталей не занимался.
Вне зависимости от метода соответствия логических и физических экстентов, логические тома предназначены для того, чтобы нести на себе файловые системы, подобно обычным дисковым разделам, причём точно те же самые — любые нативные для Linux’а: ext2/ext3/ext4, XFS, ReiserFS, JFS.
На этом терминологическое введение можно считать законченным — перехожу к описанию действий по организации хренилища данных.
Пакет LVM2, предоставляющий утилиты CLI для работы с логическими томами, устанавливается в Mint по умолчанию. Однако, как говорилось в предыдущей заметке, LVM — не тюрьма народов, и не заставляет применителя её зубрить полсотни команд этого пакета (я почти не преувеличиваю — их там 48). Потому что в репозиториях доступна графическая оболочка, интегрирующая все их функции —
Правда, здесь надо учесть, что перед её запуском я через
Однако сам раздел должен быть создан заблаговременно — зафиксировав курсор на неразмеченном пространстве, можно видеть, что кнопка инциализации просто не активна:
Вне зависимости от того, каким способом были инциализированы разделы, первым шагом после этого будет создание группы томов посредством фиксации одного из инициализированных разделов (я сделал это для самого «жирного») и нажатия кнопки Создать новую:
В вызываемой её панели достаточно задать какое-либо имя для группы томов, желательно осмысленное, например:
Впрочем, можно и изменить размер физического экстента в диапазоне от 2 до 1024 МБ — если, конечно, точно знаете, что это нужно (я — так не уверен, поэтому все остальные параметры оставил умолчальными):
После этого я полюбовался на физический и логический вид группы томов (состоящей пока из одного физического тома, раздела
После чего занялся добавлением в группу физических томов — то есть в моём случае разделов
По завершении компоновки группы томов она стала выглядеть таким образом:
Теперь настал черёд поделить эту группу на логические тома. Оно сводится к
Затем я задал размер тома и файловую систему для него — в моей системе доступны ext всех видов и XFS:
После чего осталось указать условия монтирования тома точку для оного:
Нажав OK, я получил сообщение, что и такой точки не существует и предложение её создать, от которого, разумеется, невозможно отказаться:
Тем же манеров был создан том для размещения виртуальных машин — как мне объяснили резонные люди, для них быстродействие дисковых операций также важно. На этом лимит томов с чередованием у меня был исчерпан, и оставшееся пространство я разделил на два «линейных» тома — под старые, но периодически нужные проекты, и под всякую всячину типа мультимедии:
После чего физическая и логическая картины моей группы томов стали выглядеть так:
Оставалось перезагрузиться (для страховки, можно было заказать и немедленное монтирование томов) и начать заполнять тома данными из бэкапов, разумеется, сделанных до начала не только развлечений с LVM, но и до установки Rebecca.
- вышеупомянутый полутерабайтный Crucial — на первом SATA-разъёме;
- SanDisk Extreme SSD, 120 Гбайт — на втором;
- он же, то есть точно такой же — на третьем;
- традиционный винчестер Seagate ST3500410AS о 500-х гигабайтах — на четвёртом.
Впрочем, вру: поначалу хотелось поскорей водрузить на 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на всё оставшееся пространство — без файловой системы и, сооветственно, без точки монтирования.
/dev/sdb1 и /dev/sdc1, соответственно), также без файловой системы. Вместе с /dev/sda3 они предназначались для объединения в хренилище моих рабочих данных — организация оного и является предметом данных очерков.Винчестер у меня служит для экспериментальных целей, и потому разметка его постоянно меняется, да и к нашей теме не относится. За исключением того, что первые 16 ГБ диска выделены в раздел
/dev/sdd1, служащий swap’ом для всех моих систем.Очевидно, что организация хренилища из трёх устройств требовала их объединения тем или иным способом, каковых приходило на ум четыре:
- программный RAID в «линейном» режиме;
- том btrfs с её субтомами (subvolumes);
- пул ZFS с её наборами данных (datasets);
- технология LVM (Logical Volume Manager).
Выбор 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). По размеру логический экстент равен экстенту физическому, которому он ставится в соответствие — однозначно, но одним из двух методов:
- линейным (linear mapping), когда логические экстенты последовательно привязываются к физическим сначала первого физического тома, потом второго, и так далее, подобно линейному режиму RAID;
- «черезполосным» (striped mapping), при котором «куски» логических экстентов (так называемые блоки чередования, по умолчанию равные 4 КБ) распеределяются по физическим экстентам чередующихся физических томов.
В ходе создания собственного хренилища LVM, описанного на следующей странице, оказалось, что существует ещё и метод зеркалирования. Надо полагать, что это некое подобие RAID Level 1. Но, поскольку для меня это не актуально, выяснением деталей не занимался.
Вне зависимости от метода соответствия логических и физических экстентов, логические тома предназначены для того, чтобы нести на себе файловые системы, подобно обычным дисковым разделам, причём точно те же самые — любые нативные для Linux’а: ext2/ext3/ext4, XFS, ReiserFS, JFS.
На этом терминологическое введение можно считать законченным — перехожу к описанию действий по организации хренилища данных.
Пакет LVM2, предоставляющий утилиты CLI для работы с логическими томами, устанавливается в Mint по умолчанию. Однако, как говорилось в предыдущей заметке, LVM — не тюрьма народов, и не заставляет применителя её зубрить полсотни команд этого пакета (я почти не преувеличиваю — их там 48). Потому что в репозиториях доступна графическая оболочка, интегрирующая все их функции —
system-config-lvm. В скобках замечу, что это не просто самая распространённая «морда» к утилитам lvm2, но и единственная активно развиваемая в настоящее время. Так что перво-наперво её следует установить, что я и проделал:$ sudo Ai system-config-lvm
Те, кто проникся величием оболочки Zsh и использует средства её интеграции с apt, как это описано здесь, могут последовать моему примеру, остальные же — прибегнуть к общераспространённой команде:$ sudo apt install system-config-lvm
После установки программа под именем Управление логическими томами обнаружилась в секции Администрирование главного меню Cinnamon и MATE, откуда и была запущена после ввода пароля, демонстрируя в моём случае такую картину:
Правда, здесь надо учесть, что перед её запуском я через
fdisk установил ID разделов, предназначенных на растерзание LVM, равным 8e. Что в принципе не обязательно — это можно сделать и в графической оболочке, нажав кнопку Инициализировать раздел:
Однако сам раздел должен быть создан заблаговременно — зафиксировав курсор на неразмеченном пространстве, можно видеть, что кнопка инциализации просто не активна:
Вне зависимости от того, каким способом были инциализированы разделы, первым шагом после этого будет создание группы томов посредством фиксации одного из инициализированных разделов (я сделал это для самого «жирного») и нажатия кнопки Создать новую:
В вызываемой её панели достаточно задать какое-либо имя для группы томов, желательно осмысленное, например:
Впрочем, можно и изменить размер физического экстента в диапазоне от 2 до 1024 МБ — если, конечно, точно знаете, что это нужно (я — так не уверен, поэтому все остальные параметры оставил умолчальными):
После этого я полюбовался на физический и логический вид группы томов (состоящей пока из одного физического тома, раздела
/dev/sda3):
После чего занялся добавлением в группу физических томов — то есть в моём случае разделов
/dev/sdb1 и /dev/sdc1. Для чего просто указывается группа, в которую надо добавить соотвтетсвующее устройство — поскольку группа у меня одна, то и ломать тут голову не над чем:
По завершении компоновки группы томов она стала выглядеть таким образом:
Теперь настал черёд поделить эту группу на логические тома. Оно сводится к
- определению имени тома (опять таки желательно осмысленного — на следующем скриншоте рассмотрен пример тома для текущих проектов);
- заданию метода соответствия логических экстентов физическим — в примере «чересполосного»;
- числа «полос» — поскольку в группе томов участвует три устройства, значение его очевидно;
- размера блока чередования — я сохранил умолчальные 4 килобайта, но его можно увеличить до 512 КБ (опять же не знаю, нужно ли это):
Затем я задал размер тома и файловую систему для него — в моей системе доступны ext всех видов и XFS:
После чего осталось указать условия монтирования тома точку для оного:
Нажав OK, я получил сообщение, что и такой точки не существует и предложение её создать, от которого, разумеется, невозможно отказаться:
Тем же манеров был создан том для размещения виртуальных машин — как мне объяснили резонные люди, для них быстродействие дисковых операций также важно. На этом лимит томов с чередованием у меня был исчерпан, и оставшееся пространство я разделил на два «линейных» тома — под старые, но периодически нужные проекты, и под всякую всячину типа мультимедии:
После чего физическая и логическая картины моей группы томов стали выглядеть так:
Оставалось перезагрузиться (для страховки, можно было заказать и немедленное монтирование томов) и начать заполнять тома данными из бэкапов, разумеется, сделанных до начала не только развлечений с LVM, но и до установки Rebecca.
Комментарии
Отправить комментарий