LVM и с чем его едят

(В порядке дополнения к [url:2ninxbq3]lotsman.ru/forum/viewtopic.php?f=4&t=100[/url], если кому будет интересно...)

Купил я тут винт новый и захотел на него дебиан-линукс свой перетащить. Причем не просто так, а с разбиением на разделы "по-взрослому" , чтоб, там, корень отдельно, var и tmp — тоже (чтоб, если какая софтина всё свободное место на tmp, скажем, сожрёт, так на системе это не сильно сказывалось).

Установщик дебиана автоматически что-то там сотворил, но мне показалось, что уж сильно маленькие разделы... Думал-думал... Переразбивать, если что, сильно не охота..

И вспомнил, что в линуксе давно есть такая штука, как LVM — Logical Volume Manager. (В винде тоже похожее есть, но щас не об этом). Выглядит это примерно так:
То есть, из одного или нескольких "физических томов" (physical volumes, PV) — это целые диски или их разделы — создается «группа томов» (volume group, VG), которая, в свою очередь, делится на «логические тома» (logical volumes, LV) любых нужных размеров, а на них уже поднимаются файловые системы, как на обычных разделах. Причем, размеры этих LV можно менять как заблагорассудится (хотя там есть нюансы, связанные с изменением размеров собственно ФС).

«И сделал!» ©

Подробности, если кому интересно, будут позже.

А можно ли безболезненно перевести уже установленную систему на LVM? Конвертировать, так сказать, без потери загружабельности? Можно ли это сделать в обратную сторону?

Что там с сохранностью данных? При сбое файловой системы или физическом сбое на поверхности - проблемы возникают только с одним логическим разделом или со всей группой томов?

А вообще, хотелось бы получше узнать про файловые системы ext2-3 и reiser как таковые: каковы вообще их особенности, что такое журналирование, что такое inode, это ли аналог кластеров в FAT/NTFS или вообще как там с кластерами? Какие утилиты существуют для проверки и восстановления ФС в различных ситуациях, а так же для дефрагментации?

Как грамотно перенести линукс на другой жёсткий диск или раздел или вообще на другой компьютер?

Ну, ты вопросов накидал... Вообще, есть HOWTO по этому вопросу, картинку я оттуда выдрал...

А можно ли безболезненно перевести уже установленную систему на LVM? Конвертировать, так сказать, без потери загружабельности? Можно ли это сделать в обратную сторону?

Ну, я же перенёс. ;) Хотя, определенная коррида таки была, со свежепоставленной системой было бы легче.

...Вообще (это и к другому твоему вопросу), как правило, перенос системы труда особого не составляет: разбил новый винт, как надо, смонтировал в какой-то временный каталог — и вперёд, копировать. Правда, рекомендуется это делать либо из-под single-user mode, либо вообще, загрузившись с какого-нибудь rescue диска или live-cd, во избежание. Копировать надо какой-нибудь командой, которая умеет рекурсивно обходить каталоги, но при этом не лезет на другие смонтированные ФС. По приведённой ссылке советуют что-то типа:хотя я как-то встречал способ с использованием tar.. Всяко можно, в общем. Разумеется, если были смонтированы несколько ФС, процесс для них повторяется. Затем, если нужно, внести соответствующие изменения в /etc/fstab и конфиги загрузчика (/etc/lilo.conf или /boot/grub/menu.lst) на новом загрузочном диске. Ну, и загрузчик на новый диск зафигачить. По ссылке описан вариант для grub'а, а для lilo будет что-то типаНу, всё, вроде... В идеальном случае, по крайней мере. ;)

У меня «коррида» была связана с тем, что я ещё и /boot отдельный сделал, до этого всё на корневой ФС валялось. Без этого, как я понял, было не обойтись, поскольку само ядро грузиться с LVM не умеет — то есть vmlinuz и initrd.img должны лежать на «обычном» разделе (при этом в inird ещё должны присутствовать модули для device-mapper'а, но в штатных-то сборках они вроде есть). Пока я допёр, как это всё объяснить lilo, загрузившись с rescue диска — запарился...

(Там ещё оказался глюк — то ли дебиановский, то ли ядерный — что lilo в качестве рута понимает для LV только имя устройства типа /dev/mapper/vg0-root, но не /dev/vg0/root, хотя последнее имя — просто симлинк на первое, и такой вид имён для LV более распространён вроде бы...)

По поводу надёжности: ну, вообще-то VG-дескриптор бэкапится, и можно в случае чего накатить его обратно — в howto есть пример... В случае физических дефектов — фиг его знает, там дисковое пространство выделяется кусками (physical extent, PE), так что, по идее, дефект не должен больше чем на один экстент влиять.. Но это разбираться надо.

А про ФС вообще — ну, я глубоко в этом не рылся... inode — это структура, хранящая инфу о файле, грубо говоря, примерно то, что останется от записи в fat-овском каталоге, если отодрать от неё имя (поскольку в posix-системах имён у одного файла может быть много). Там, владелец, права, времена создания/доступа и всё такое.. Про кластеры — знаю, что блоки в ext2 как-то в группы объединяются, но подробностями не интересовался пока... Если охота подробностей — /usr/src/<версия ядра>/Documentation/filesystems/ в исходниках ядра инфа по структурам должна быть...

Вообще надо какой-нибудь русскоязычный FAQ найти... На ЛОРе в разделе с доками что-то полезное было, кстати, несмотря на всю его одиозность...

Кстати, есть ещё Hard Disk Upgrade Mini How-To ...

По поводу утилит: ну, mkfs — это типа format, fsck — chkdsk... С ними тоже интересно — так как ФС может быть много разных, эти утилиты — только запускалки, а работу делает свой «модуль» для каждой ФС (который при этом должен быть установлен). Скажем, если натравить fsck на vfat-раздел, вызовется fsck.vfat. Ну, и напрямую этот модуль вызвать тоже можно. (Кстати, вызывать fsck на смонтированную ФС — крайне нежелательно!).

Польза от дефрагментации для ФС с древовидной структурой блоков данных (в т.ч. NTFS) — IMHO, сомнительна (по крайней мере, для обычных условий). Но какой-то defrag для ext2 существует, никогда не юзал...

Еxt3 — это та же ext2, только с журналированием, то есть инфа о любых изменениях в файлах сначала пишется в журнал, а потом уже производится фактическое действие. В случае ошибки инфа из журнала помогает восстановить стабильное состояние ФС. Там ещё разные уровни журналирования могут быть в зависимости от объема инфы и порядка её сохранения...

Ext3 от других журналируемых систем (типа XFS) в выгодную сторону отличается тем, что её журнал независим от собственно структур ФС. То есть существующую ext2 можно легко превратить в ext3, создав журнал, и наоборот; можно смонтировать ext3 (ну, предварительно штатно отмонтированную, чтобы в журнале недописанные транзакции не висели) как ext2 и т. д.

Ещё у ext2/3 можно без проблем менять размер раздела, в том числе и на смонтированной(!) системе (ну, с определенными оговорками). Хотя, прежде чем такие штуки проделывать, крайне желательно читать документацию...

Про разные ФС в англовики достаточно подробные статьи, кстати, со ссылками...

Кстати, насчёт конвертации в LVM. Чё-то не нашёл, но попадался мне метод преобразования разделов на одном и том же диске - главное, чтоб место свободное оставалось. Поэтапно - ресайзишь ext2-раздел, на свободном месте создаешь PV/VG/LV, переписываешь, ресайзишь снова, создаешь еще PV, добавляешь в группу, ну, и так далее...