Logical Volume Manager - это очень полезная штука, позволяющая легко и гибко манипулировать дисками и разделами. Только название у нее страшное, а мануалы еще страшнее. Я постараюсь на пальцах, не прибегая к источникам, объяснить как это работает, затрагивая лишь аспекты домашнего использования. Примитивно, но достаточно для начала.
Разберемя, что такое LVM и что он нам дает. У Вас есть второй (третий, пятый) винт? Они маленькие, но их несколько. Так часто решается проблема нехватки свободного места. Но вот что неудобно - куча разделов. Хотелось бы иметь один большой раздел, а не много маленьких, и не заморачиваться вопросами "на каком разделе у меня осталось место" или "на какой диск я кинул тот файл". Словом, избавиться от беспорядка. И тут приходит на помощь LVM. Он позволяет Вам магическим образом соединить все накопители в один, и больше не задумываться о том, как эффективно распределить разделы между дисками. А может у Вас всего один винт, но Вы собираетесь приобрести второй? Тогда LVM поможет Вам увеличить уже имеющиеся разделы за счет нового накопителя. Или же все-таки у Вас один винчестер и второй заводить Вы не собираетесь? Ну, я надеюсь, раздел-то у Вас не один? Как минимум один для системы и второй для личных файлов? И, скажем, места для системы стало нехватать? Тогда LVM снова придет к Вам на помощь. Вам не придется часами двигать разделы по всему винту. Достаточно освободить место в любой его части за счет уменьшения одного из разделов, и это свободное место тут же может быть приклеено к любому другому разделу, где бы он не находился.
Словом, Вам больше не нужно задумываться о физической конфигурации жестких дисков. Все, о чем Вы задумываетесь - это назначение разделов и объем доступного места. В дополнение к этому мы имеем такие удобства, как человеческие названия разделов вместо нумерации, расширение разделов на лету без остановки системы, создание снимка раздела без остановки системы, и, возможно, что-то еще, в чем я еще сам не разобрался :)
Чего LVM вашей системе точно не добавит - так это надежности. Выход из строя одного из физических носителей может повлечь за собой утрату данных со всех разделов. Однако, о резервных копиях Вы должны побеспокоиться в любом случае, так как ничто не вечно, и поломка жесткого диска - это лишь вопрос времени. Так что, советую не играть в русскую рулетку со своими файлами, а делать резервные копии настолько часто, насколько это важно для Вас.
Теперь поговорим о внутренностях. Название системы переводится как "менеджер логических томов". Логические разделы (Logical Volume, они же тома) - это то, что мы получаем в итоге при использовании LVM. На них мы живем, их мы форматируем в нужные нам файловые системы, на них мы и храним свои файлы. В папке /dev они также, как и обычные физические разделы, доступны в виде файлов. Вот мои логические разделы:
$ sudo ls /dev/vg0/ lv_home lv_root
У меня их всего два, больше мне не надо. Вот только проблема состояла в том, что в приобретенном мною eee pc всего два маленьких флешовых накопителя: примерно 4 и 14 гектаров. Для системы мне 4 мало, а 14 много. В общем - ни туда, ни сюда. Так я и стал разбираться с LVM.
Все пространство, выделенное под логические тома, называется группой томов (Volume Group). Я бы назвал это логическим диском. Как физический диск состоит из томов, так и группа томов состоит из логических томов. Отличие в том, что тут работают другие "законы физики". Логические тома вовсе не обязаны физически быть расположенными друг за другом и непрерывно. Они состоят из кусочков, которые распределяются по всей группе в соответствии с указанной политикой распределения. А группа томов может увеличиваться или уменьшатсья в размере за счет присоединения или отсоединения устройств. Любой раздел можно увеличить за счет имеющегося свободного пространства. И если понадобилось дополнительное место для какого-то раздела, его можно освободить за счет уменьшения любого другого логического тома. При этом вовсе не нужно двигать разделы, чтобы переместить свободное место под нужным том. Расширяемый том заполнит свободное пространство, где бы оно не находилось. В итоге, кусочки логического раздела могут быть физически разбросаны по носителям. Но нам до этого никакого дела. В том и прелесть. Все, о чем мы задумываемся - размер разделов. Где и как они физически расположены - это не важно.
У меня всего одна группа разделов. Я назвал ее vg0. Но их может быть и несколько. Однако, я не могу себе представить, зачем мне лично это может быть нужно в домашних условиях. Если Вам вдруг покажется, что в вашем случае их нужно несколько, то имейте в виду: группа томов не так гибка как логические разделы. Если планируете изменять размер одного раздела за счет другого, держите их в одной группе. Иначе теряется вся простота использования, и далее Вы увидите почему.
Киты (или слоны, если хотите), на которых стоит группа разделов - это физические разделы. Их не нужно форматировать в какую-то файловую систему. LVM использует данные ему разделы целиком и полностью, паспределяя по ним кусочки логических томов. Отсюда название "группа разделов" приобретает некий двойственный смысл. С одной стороны это группа логических разделов, с другой - физических. Важно понимать, что как только Вы присоединяете физический раздел к группе, теряется возможность изменять его размер. Это как пилить ветку, на которой сидишь. И если Вы захотите в будущем отсоединить физический раздел от группы, чтобы изменить его размер или вообще целиком отдать другой системе, нужно будет перенести все данные с него на другие разделы. Конечно, Вам не придется вручную переставлять байты и блоки, LVM может сделать это для Вас. Но отмонтировать все файловые системы таки придется. Еще более важно осознавать, что если у Вас всего один винт с одним разделом, и Вы устанавливаете на него LVM, то освободить место под другую систему (под Windows например) будет затруднительно. Так что, если подозреваете такую возможность, то побейте винт сразу на несколько физических разделов, прежде чем скармливать его менеджеру логических томов.
И если с китами и слонами есть некоторые нюансы, то с черепахой, на которых они стоят, все просто. Физический накопитель просто является носителем физических разделов, используемых LVM. Он также может иметь и другие разделы, отформатированные под определенные файловые системы. Это не будет иметь никакого отношения к LVM. Нет разницы на каком диске находится физический раздел. Может быть только разница в скорости чтения/записи. Если это важно, то в момент создания логических томов можно заставить их использовать определенные физические тома по вашему усмотрению.
Получаем вот такую иерархию понятий снизу вверх: накопитель, физический том, группа томов, логический том. Все просто, но легко запутаться. Особенно, если групп несколько. Если она одна, то на нее, как на понятие, можно вообще по большому счету не обращать внимание. Тогда получаем упрощенную модель: логические тома располагаются на физических. Каждый логический том может лежать одновременно на нескольких физических томах. Причем он не обязан заполнять их полностью. Более того, по умолчанию LVM будет распределять каждый логический раздел по разным физическими носителями (наверное, для распределения нагрузок).
Я думаю, это все, что нужно понимать для начала. Довольно теории. Перейдем к практике. Так сказать, how to use.
Возьмите ваш винчестер и разбейте его. Не о пол конечно, а на разделы. И используйте его с LVM. Это все. Пакет называется lvm2, список команд найдете в официальном мануале или в гугле. При установке убуты, если воспользоваться консольным установщиком, можно сразу разметить диск под LVM. Только boot поместите в обычный раздел (метров 100-200 хватит), чтобы grub не растерялся, пытаясь загрузить вашу систему. Для управления всем этим делом можно воспользоваться хорошей графической утилитой: kvpm. Там все просто. И не забудьте о резервных копиях. Теперь точно все.
Заметку не читал, но одобряю :)
ОтветитьУдалитьСам использую LVM года четыре. Моя vg0 пережила две смены дистрибутивов, одну смену архитектуры (с x86 на amd64), и три винчестера.
Заманчиво, но опасно. Летит один винт - летят все файлы (при дефолтных настройках; даже если хитро настроить, то восстановление обещает быть интересным процессом). А где, интересно, хранится информация о том, где какой файл физически лежит?
ОтветитьУдалитьПро бекапы хорошо написано, но на практике спасти сотни гигабайт данных без рейда сложно. При двух и более винтах можно дублировать особо важные данные на нескольких винтах. А LVM, к сожалению, все перепутывает.
Хотелось бы иметь такую же надстройку, только над физическими разделами с файловой системой. Это бы повысило надежность. Похоже, наверное, на fuse-based.
Никита, Вы изначально готовитесь к поломке винта, планируя восстанавливать файлы из покалеченного устройства. Это ли не опасно? Важные данные всегда должны быть минимум в двух копиях. А неважные не должны Вас заботить.
ОтветитьУдалитьНа практике, создание регулярных бекапов - это не сложно. Вы, наверное, просто не пробовали. В конце концов, хотите рейд (не знаю зачем он дома) - пожалуйста. Что мешает использовать LVM поверх него? Это ведь два разных уровня абстракции. Или я не прав? Вроде же и статьи на эту тему есть...
В конце концов, возможно, ничто не мешает даже проложить посередине файловую систему. Правда смысла в этом не вижу. Но какая разница этому LVM, какие он разделы использует. Он небось и знать не знает что ему подсовывают. Берет указанное устройство и использует.
В общем, мне кажется, это все решаемо. Было бы желание.
lvm без raid - прямой путь к потере данных, поэтому сам по себе он практически никогда не используется (дефолтная инсталляция федоры - плохой пример). Поэтому lvm - скорее серверное решение, чем клиентское. И на серверах оно себя проявляет во всей красе.
ОтветитьУдалитьЯ не готовлюсь восстанавливать файлы, я просто хочу, чтобы если сломается один винт, то на другом остались файлы, которые были там записаны. Не более, не менее.
ОтветитьУдалитьРегулярные бэкапы я делаю, причем с винта на винт для безопасности. Две копии на одном диске не спасут при его поломке. С LVM мы даже не знаем где физически хранится каждый файл. Да и данные о разметке нужно хранить где-то на винте. На каком? ;)
Разве возможно настроить LVM поверх файловой системы? Никогда не слышал о таком.
С LVM можно точно указать на каком физическом томе находится логический том.
ОтветитьУдалитьandy128k, а смысл тогда в LVM? Мы же хотим наоборот объединить пространство, т.е. несколько физ. томов под одним логическим.
ОтветитьУдалитьСмысл не только в объединении (с этим и RAID справляется), а в возможности гибко менять размеры файловых систем. Также легко можно менять и физические носители. Выше я писал, что у меня одна и та же группа пережила три диска. В последний раз случилось так: на диске обнаружились bad-блоки, в группу был добавлен новый диск, а старый из группы удалён. LVM перенесла все данные в фоновом режиме без остановки системы и без отмонтирования файловых систем.
ОтветитьУдалитьТакже в LVM изменение размеров ФС позволяет избегать перемещения разделов. Это тоже, ИМХО, надёжнее чем перемещение многогигабайтных разделов по дискам. Кстати, не всякое перемещение возможно (просто), ЕМНИП, ext2/3 нельзя перемещать, а только изменять размер.
> В последний раз случилось так: на диске обнаружились bad-блоки, в группу был добавлен новый диск, а старый из группы удалён. LVM перенесла все данные в фоновом режиме без остановки системы и без отмонтирования файловых систем.
УдалитьОбъясните, а как вы без перезагрузки и без размонтирования всунули в системник новый жёсткий диск? "на горячую?" А стоит ли так делать? :)
Может, на каких-нить серверах, которые останавливать никак нельзя даже на минуту, на которых используют SAS-диски горячая замена - дело обычное. Но на домашних компах, сдаётся мне, на горячую диски лучше не подключать. :) А если комп всё равно вырубать - ничего сложного в том, чтобы скопировать инфу со старого диска на новый используя любой livecd. И никакой lvm не нужен...
В чём профит, объясните?
Я вот совсем недавно двигал ext3 - без проблем.
ОтветитьУдалитьНикита, так никто ж не говорит, что нужно все свои имеющиеся винты в обязательном порядке объединять под LVM. Если у Вас есть винт для бэкапов - отлично, используйте его для бэкапов. Если и добавлять его в группу, то только в отдельную. Потому что бэкапы должны быть отделены физически, а не логически. Тогда при поломке основного носителя у Вас не будет проблем с резервными данными.
а я все же предпочитаю использовать mhddfs, когда хочу чтобы у меня разные разделы дисков были как один, да и безопаснее если вдруг с одним из разделов что-то случится. Даже как-то давно статейку писал про это дело.
ОтветитьУдалитьТоже интересно, спасибо.
ОтветитьУдалитьТак может и ссылочку на вашу статью сразу скинете? :)
Интересно.
ОтветитьУдалитьЛВМ штука интересная, но преимуществ на домашней машине практически никаких. Правильно написано что можно объединять место, если не страшно потерять всю информацию с них. Так как в случае сбоя fsck не поможет и придется форматировать все под чистую.
Кроме того, нет поддержки загрузчиков. Граб и остальные окажется грузится с такого и будет прав.
Хотел бы добавить вот еще что. В один страшный день, когда я поставил Виндус на свой линукс раздел с быстрым форматированием был не так печален так как я без труда востановил все файлы через fsck с указанием мастер сектора файловой система екс3. Вот так вот. И такой же фокус низачто не пройдет с LVM разделами.
УДачи!
Точно, mhddfs как раз то самое, что я имел в виду под fuse-based. Зачетная штука!
ОтветитьУдалитьЗабыли написать, что LVM потребляет определенный % CPU. У меня на p4 3000 при заливке информации на сервер процессор загружен до 30%.
ОтветитьУдалитьИ второй момент. Какую ФС ставить на LVM?
Тут нюанс в inode. А именно в ext2/ext3 inode создаются при создании ФС. Т. е. если создадите очень маленький раздел и растяните его в очень большой и начнете заливать очень много мелких файлов то inode у вас могут просто закончиться :)
raiserfs же в свою очередь создает inode по мере надобности.
Спасибо, очень интересные ньюансы.
ОтветитьУдалитьА mhddfs не так сильно загружает процессор?
Я использую LVM на домашнем компьютере уже несколько лет (где-то с 2006-го). Никакой существенной нагрузки на CPU не видел вообще. Использую reiserfs где только можно. Вне LVM только /boot под ext2.
ОтветитьУдалить>Никакой существенной нагрузки на CPU не видел вообще.
ОтветитьУдалитьИспользую RAID1+LVM (2 hdd) на сервере./boot - ext2, / - ext3. Cоздан vg на котором 8 логических томов. На логических томах raiserfs. Решил скопировать документы юзеров с одного тома на другой. Копирую командой cp -r. Загрузку смотрю top'ом. Процесс cp отьедает в среднем 20%. Пики 18% и 41%.
К сожалению, это все просто личные впечатления. Вот если бы сравнительные тесты провести на одном и том же железе с LVM и без.
ОтветитьУдалить> Процесс cp отьедает в среднем 20%. Пики 18% и 41%.
ОтветитьУдалитьНу и какова доля LVM в этом? Или вы хотите сказать, что копирование без LVM занимает ноль целых ноль десятых?
>Ну и какова доля LVM в этом? Или вы хотите сказать, что копирование без LVM занимает ноль целых ноль десятых?
ОтветитьУдалитьНет. Занимает в среднем 2%. В пиках до 4%.
Кстати, только что заливал по сети на фтп (vsftpd, LVM) файл в несколько гиг. Нагрузка на процессор процесса vsftpd 45%, в пиках до 50%. После окончания падение общей загрузки процессора практически до 0%.
Что-то я не увидел никакой разницы. Специально освободил один раздел и отформатировал его в ext3, как и под LVM. загрузка примерно одинаковая: подскакивает до 10-15%, но большую часть времени процесс находится в ожидании ввода/вывода.
ОтветитьУдалить$ time cp /tmp/work.tar.gz /tmp/work2
real 0m20.806s
user 0m0.036s
sys 0m2.584s
$ time cp /mnt/work.tar.gz /mnt/work2
real 0m45.776s
user 0m0.032s
sys 0m3.260s
Тест повторял несколько раз. Как видно, примерно одинаково. Только реальное время выполнения на обычном разделе у меня существенно больше, потому что второй накопитель медленнее.
Такой же результат с множеством файлов:
$ time cp -R /usr/share/kde4/ /tmp/tmp_kde4
real 0m39.753s
user 0m0.276s
sys 0m4.476s
$ time cp -R /mnt/kde4 /mnt/tmp_kde4
real 1m25.196s
user 0m0.308s
sys 0m4.388s
storm, Вы можете провести реальные сравнительные тесты, в которых будет исключено влияние внешних факторов? Т.е. чтобы все было идентично кроме наличия LVM. И чтобы ваш тест можно было повторить и наглядно сравнительно убедиться в том, что LVM действительно существенно нагружает CPU. Был бы Вам очень признателен, если бы Вы помогли разобраться и понять как на самом деле обстоят дела. Это для меня важно, ибо машинка довольно слабенькая :)
Я цифр не назову, но я использовал LVM на медленной машине и тормозов не припоминаю. Машина была PIII 600MHz, 386MB RAM, 10GB HDD.
ОтветитьУдалитьКажется мне, загрузку вызвал SFTP :)
ОтветитьУдалитьПоправка к моим тестам.
ОтветитьУдалитьЯ вернул LVM на "медленный" раздел, и провел тест еще раз. И снова те же показатели, только реальное время короче. Так что, накопитель вовсе не медленный, как я думал. Получается, просто LVM каким-то образом ускоряет процесс копирования.
Я также порылся в инете и нашел довольно интересный тест скорости LVM против обычного раздела. Из них видно, что LVM нисколько не уступает обычным разделам ни по скорости, ни по загрузке процессора. Может даже чуть-чуть выигрывает :)
http://www.umiacs.umd.edu/~toaster/lvm-testing/
прочитал всю статью, все комменты. для себя так и не получил ответа. raid 1(зеркало) или raid 5 классно но если один из винтов доскачет до degraded - пересобирать raid долго. поясните как оно с lvm? товарищ andy128k описывает похожую ситуацию но только при бэдблоках, если вылетает винт - данные не восстановить?
ОтветитьУдалитьА я вот хочу попробовать с помощью LVM отрезать беды...
ОтветитьУдалитьВаляется вон бедовый 3Тб... Нарезать его на разделы располагающиеся там где нет бедов, объединить их в группу томов и создать раздел. И можно винтом пользоваться пока беды не поползут дальше. Не знаю можно ли отключать тома от группы - но таким образом можно попробовать предусмотреть вывод несколько разделов на которых появятся беды...