Рисунок 1

Сам логический том также состоит из песчинок, называемых LE (logical extent), которые сопоставляются реальным физическим physical extents. Если в дальнейшем понадобится изменить размер logical volume, то это можно будет проделать как раз на величину, кратную physical extents. Такая взаимосвязь физических и логических extent обозначается термином mapping. И ещё, так как фактически нет разницы, какому PE противопоставить LE, то это можно сделать двумя вариантами – линейным (linear mapping) и чередующимся (striped mapping). В первом случае всё просто: непрерывной последовательности физических extent ставится в соответствие столь же непрерывная последовательность логических extent. Во втором – непрерывная последовательность логических extent связывается с чередующимися между различными физическими носителями extent. Эта схема напоминает нулевой (полосатый) RAID-массив. При этом если разместить два диска на различных IDE-каналах, можно добиться некоторого повышения производительности дисковых операций. Но надёжность в таком случае ниже, т.к. в случае вылета одного диска можно потерять всё. Поэтому бэкап в последнем случае играет не последнюю роль. И ещё не стоит смешивать в одной VG оба метода, если есть в этом необходимость, то для striped mapping создайте отдельную volume group. Как говорил один из моих преподавателей: «Природу не обманешь, за всё надо платить». Естественно, за удобства приходится расплачиваться, в нашем случае это 10-15% процессорной мощности. Причем перенос файловых систем с физического на логический уровень на скорости дисковых операций не отразился в linear случае.

От теории к практике

Теперь попробуем создать logical volume и подключить его как обычную файловую систему. Для начала давайте определимся, что не надо класть в LV. Так, нет особого смысла помещать туда каталог /boot, в котором содержится ядро и Grub. Его стоит вынести в отдельный раздел размером 50 Мб (с запасом) и в файле /etc/fstab прописать такие строки, чтобы он не автоматически монтировался при загрузке.

/dev/hda1 /boot ext2 noauto 1 2

Применять журналируемые файловые системы в этом случае смысла особого нет, а при смене ядра (довольно редкое занятие) данный каталог всегда можно примонтировать вручную. Также, наверное, не стоит помещать туда и следующие каталоги /etc, /proc, /lib, /mnt, /bin, /sbin, /dev, /root, swap и /tmp (хотя это всё относительно). Обычно состав их более-менее статичен и много места не занимает, так, корневой раздел в CRUX такого состава получился у меня всего навсего 300 Мб, остальное находится в /usr, /var и /home. При большом количестве внесистемного софта также следует вынести в отдельный каталог и /usr/local с /opt (я обычно делаю символическую ссылку ln -s /usr/local /opt, чтобы голову меньше ломать). Дополнительно ко всему у вас всегда будет возможность зайти в систему из-под root в случае аварийных обстоятельств. LVM можно использовать при наличии в системе и одного жёсткого диска, но наибольшую гибкость данная технология даёт при использовании двух и более дисков в системе. Для эксперимента возьмем два раздела /dev/hda4 и /dev/hdс2.

Рисунок 2

Общее распределение разделов на дисках будет таким:

n  /dev/hda1 – /boot

n  /dev/hda2 – swap (содержит и /tmp)

n  /dev/hda3 – корневой (/etc, /proc, /lib, /mnt, /bin, /sbin, /dev, /root)

n  /dev/hda4 – будет использован с LVM

n  /dev/hdс1 – swap

n  /dev/hdс2 – будет использован с LVM

Необходимый софт

В большинстве современных дистрибутивов, за исключением разве ориентированных на power user, всё необходимое для работы уже имеется. Так, например, программа установки Red Hat 9 позволяет создать LVM (и софт-RAID) в графическом режиме (рис. 2), но, если честно, мне она не показалась интуитивно понятной. Для поддержки технологии ядром при компиляции должны быть включены следующие опции. В секции Multi-device support (RAID and LVM) нужно включить поддержку самих Multiple devices и далее собственно менеджера логических томов (Logical volume manager (LVM) support).