RAID и LVM
Как уже говорилсоь, в процессе подготовки диска к созданию файловых систем подчас возникает задача не только размежевания, то есть разбиения диска на разделы, но и объединения - отдельных разделов в их массивы или логические тома. К рассмотрению инструментария для этого мы теперь и обратимся.
Как и средства разметки, инструменты слияния дисков в массивы существенно различны в Linux и BSD-системах. А технология LVM вообще свойственна только первой ОС.
Как это в обычае в Linux, программный RAID любого выбранного уровня можно создать более чем одним способом - конкретно, двумя. Однако на каком бы способе мы ни остановились, и какой бы RAID не выбрали, в любом случае потребуется выполнение некоторых условий и некоторый комплекс однотипных действий.
Первое условие, разумеется, - физическое наличие более чем одного диска. Причем очевидно, что число их для линейного режима значения не имеет, а для level 0 предпочтительно четное количество. Опять же повторюсь: при линейном режиме порядок подключения дисков к контроллерам большой роли не играет, при выборе же нулевого RAID'а желательно разнести их на разные контроллеры.
Далее, на дисках необходимо создать (средствами fdisk, cfdisk, parted или любыми дистрибутив-специфичными утилитами) два раздела и присвоить соответствующий идентификатор - fd (в шестнадцатеричной нотации), который так и называется - RAID Auto detection. В принципе, это не обязательно, но здорово упрощает жизнь.
Теперь - ядро системы: для использования программного RAID'а в его конфигурации должны быть включены соответствующие опции в пункте Multi-device support главного меню, генерируемого по команде
$ make menuconfig
А именно:
Общая поддержка "многочленных" устройств может быть только встроена в ядро, прочие же опции либо встраиваются, либо подключаются в качестве модулей (последнее имеет место быть по умолчанию в прекомпилированных ядрах большинства известных пакетных дистрибутивов Linux).
В рассматриваемом нами случае это безразлично. Встраивание поддержки RAID в ядро обязательно только в том случае, если на массиве располагается корневая файловая система и (или) он выступает в качестве загрузочного устройства - ни того, ни другого мы договорились не делать. Да и то, при должном конфигурировании виртуального загрузочного диска (initrd) даже в этих случаях можно обойтись модулями.
Теперь можно приступать к созданию RAID-массива. Для чего потребуется соответствующие инструменты, объединяемые в один из двух пакетов - традиционный raidtools и более новый mdadm.
Первый многократно описан. Существует фундаментальный The Software-RAID HOWTO (hThe Software-RAID HOWTO), написанный Якобом Остергардом (Jakob Ostergaard) и переведенный на русский языкрусский язык Максимом Дзюманенко. Немало внимания RAID-массивам уделил в своей серии публикаций на сайте IBM-Linux Дэниэл Роббинс (часть 1 - http://www-106.ibm.com/developerworks/linux/library/l-raid1/index.html, часть 2 - http://www-106.ibm.com/developerworks/linux/library/l-raid2/index.html). И все эти документы посвящены исключительно использованию инструментария raidtools. Котрый, кстати, имеет своим местопребыванием сайт Red Hat: http://people.redhat.com/mingo/raidtools).
А вот о mdadm сведения можно почерпнуть только из его штатной документации . Русскоязычных его описаний мне не встречалось. Главное же, mdadm много превосходит raidtools с точки зрения удобства употребления (в очередной раз вынужден подчеркнуть - я рассуждаю с позиций пользователя, а не администратора сервера).
Итак, mdadm. Далеко не факт, что он имеет место быть в вашем дистрибутиве. Не беда - его всегда можно скачать - либо с автоского сайта (http://www.cse.unsw.edu.au/%7Eneilb/source/mdadm/, либо с канонического сайта Linux (http://www.kernel.org/pub/linux/utils/raid/mdadm/) в виде тарбалла исходников. Обращение с которым, после обычной распаковки, столь же своеобычно - последовательность команд make и make install (обратим внимание - программа столь проста, что в предварительном конфигурировании посредством ./configure не нуждается).
По завершении установки мы обнаруживаем единственный исполняемый бинарник /sbin/mdadm (изменить каталог для него можно, залезши руками в path2/mdadm_src_dir/Makefile, но - нужно ли? в каталоге /sbin программе такого рода самое место) и пару относящихся к нему man-страниц (mdadm.conf и mdadm), содержащих вполне достаточно информации для того, чтобы приступить к делу создания собственного RAID'а.
Нетрудно догадаться, что раз из всего пакета в итоге образовался только один бинарник, именно его и следует запустить для создания массива. Для образования RAID'а команда mdadm требует одной из двух опций: -C (эквивалент --create) или -B (сиречь --build) - в обоих случаях обратите внимание на регистр краткой формы. В чем разница между ними?
Опция -B создает массив без собственного суперблока. Что для пользователя снимает ряд преимуществ инструмента mdadm - и потому к этой опции мы возвращаться не будем. А вот опция -C этот суперблок учреждает - и ею определяется вся сила программы mdadm.
Итак, опция -C. Элементарная логика подсказывает, что она, будучи основной, требует аргумента - имени файла устройства, соответствующего создаваемому массиву (например, /dev/md0 или, при задействованной файловой системе устройств, /dev/md/0), а также указания некоторых дополнительных данных, как то: его уровня (режима), количества устройств в нем и, наконец, имен файлов устройств, массив составляющих. Что и достигается указанием опций --level=# (или, сокращенно, -l #) и --raid-devices=## (в краткой форме -n ##), после которой перечисляются имена файлов, вроде /dev/hda3, /dev/hdb3). В итоге простейший случай создания RAID'а параллельного режима выглядит следующим образом:
$ mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/hd[a,b]3
Для массива нулевого уровня допустимые значения опции --level также raid0 или stripe. А для массива линейного режима она примет значение linear (то есть -l linear).
Для параллельного режима дополнительно можно задать еще один параметр - размер блока "распараллеливаемых" данных (chunk - очевидно, что для массива в линейном режиме это смысла не имеет), в виде одноименной опции --chunk=значение (в килобайтах, в краткой форме -c ##).
Теоретически рассуждая, чем больше величина chunk'а, тем выше должно быть быстродействие массива. Однако практические измерения этого не подтверждают. И потому вполне можно опустить данную опцию - при этом умолчальное значение составит 64 Кбайт.
В любом случае после указанной выше команды RAID создан, в чем легко убедиться командой
$ less /proc/mdstat
Более того, он сразу же готов к использованию - на нем можно создать ту или иную файловую систему. Хотя, с другой стороны, никто не запрещает поделить его программой fdisk на разделы (по моим наблюдениям, cfdisk на это не способен).
Внимательный читатель, особенно знакомый с документацией по raidtools, спросит: пардон, а где же тут конфиг, описывающий RAID-массив? Отвечаю: при использовании mdadm, установке соответствующих идентификаторов на составляющих массив разделах (вспомним добрым словом RAID Auto detection), и, наконец, создании массива с собственным суперблоком (вот зачем нужна была опция -C) необходимости ни в каком конфиге не возникает.
Однако при желании конфигурационный файл для массива создать можно - в некоторых случаях это упростит дальнейшее им управление. Для чего опять обращаемся к команде mdadm. Кроме упомянутых выше основных опций, она имеет еще несколько дополнительных. И в форме
$ mdadm --detail --scan
способна вывести информацию о существующем массиве. Достаточно перенаправить ее вывод в файл (таковым традиционно будет /etc/mdadm.conf) - и соответствующий конфигурационный файл будет создан.
Теперь время вспомнить о других опциях команды mdadm. С одной из них мы познакомились раньше - это --help для получения подсказки. Каковую, кстати, можно конкретизировать, указав эту опцию совместно с какой либо из других основных опций. Например, команда
$ mdadm --create --help
распишет нам процесс создания массива в деталях.
С другой опцией (--detail, или -D - все опции, отнесенные к числу основных, в сокращенной форме даются в верхнем регистре) мы столкнулись только что: она призвана выводить информацию о существующих массивах.
Близкий смысл имеют и опции --query и --examine (в сокращенной форме, соответственно, -Q и -E) - за деталями можно обратиться к man-странице.
А вот опции --assemble (-A) и --monitor, или --follow (-F) предназначены для управления существующим массивом. В частности, они позволяют добавить к нему новое устройство или удалить существующее. Правда, при выполнении некоторых условий. Впрочем, и об этом подробно расскажет тетя Маня, если попросить ее должным образом.
В общем, создание RAID-массива средствами mdadm - процесс очень простой (а управление им пользователю на десктопе, скорее всего, не понадобится). Так что, если нет необходимости в дополнительных возможностях, предоставляемых LVM, при наличии двух дисков есть резон им и ограничится.
Справедливости ради следует сказать пару слов и об инструментарии raidtools и способах обращения с ним. В отличие от mdadm, он требует обязательного наличия конфигурационного файла - /etc/raidtab. Причем создать его нужно (вручную, в текстовом редакторе) до запуска каких-либо команд по созданию RAID'а.
Впрочем, структура /etc/raidtab очень проста. Стоит только помнить, что каждый из перечисленных ниже пунктов выступает в отдельной строке, значения в которой отделяются пробелами или табулятором - все же база данных (хотя и простая), а не хвост собачий... Итак:
Наконец, последовательно перечисляются имена всех объединяемых устройствс их порядковыми номерами, начиная с нуля:
device /dev/hda3 raid-disk 0 device /dev/hdb3 raid-disk 1
Закончив редактирование /etc/raidtab, активизируем RAID командой
$ mkraid /dev/md0
и просмотром файла proc/ mdstat убеждаемся, что все произошло так, как и задумывалось.
Сложнее, конечно, чем использование mdadm, но не намного, не так ли? Тем более, что весь процесс создания RAID именно применительно к инструментарию raidtools в деталях расписан в перечисленных выше документах.
Главное различие между mdadm и raidtools таково (спасибо Владимиру Холманову за соответствующие комментарии): первый содержит один большой универсальный бинарник, что удобно для интерактивной работы с RAID. Пакет же raidtools содержит несколько специализированных небольших бинарников, а размер файла - важный параметр при использовании загрузочного initrd. Поэтому по традиции, в сценариях инициализации используются команды из raidtools. Даже если массив создается с помощью mdadm, после перезагрузки проблем возникнуть не должно - если для объединяемых в массив разделов был установлен идентификатор типа fd.
В BSD-системах также имеется два разных механизма создания программных RAID-массивов - классический ccd (Concanetade Disk driver) и более новый vinum. Это - не два разных набора инструментов, а именно две различные технологии, обладающие разными возможностями. В частности, vinum позволяет разместить на дисковом массиве корневую файловую систему, на что ccd не способен. Впрочем, с задаче размещения всех остальных ветвей последний справляется успешно, и к тому же проще в использовании, поэтому ниже чеь пойдет только о нем (заинтересованным в механизме vinum предлагается обратиться к FreeBSD Handbook в русском переводе или DragonFly Handbook - в оригинале).
Итак, ccd - драйвер слияния дисков. Средство, как я уже сказал, весьма древнее - man-страница датирована 1995 г., - а значит, проверенное временем. Позволяет создавать программные RAID-массивы типа нулевого (stripping) и первого (mirroring) уровней.
Как уже было сказано, ccd не позволяет разместить на массиве корневую файловую систему.
Поэтому перед его использованием необходимо установить нашу операционку на первый из наличных дисков, задействовав только раздел /dev/ad0s1a и оставив остальное пространство неразмеченным. После чего выполнить на обоих дисках разметку разделовдля конкатенации, что может быть выполнено двумя способами. Согласно первому, в соответствие с заветом дедушки Ленина, прежде чем объединиться, следует решительно размежеваться, согласно второму - как раз наоборот.
Суть второго способа - интуитивно понятна (и аналогична построению RAID'а в Linux с помощью mdadm): два дисковых раздела одинакового объема сливаются воедино, а потом это объединенное пространство, воспринимаемое как единый слайс, делится на разделы под нужные файловые системы. Первая же схема выглядит более сложной - сначала деление слайсов на обоих дисках на симметричные разделы под будущие файловые системы, а потом попарное их слияние. Именно на втором способе мы и задержим свое внимание.
Итак, на каждом диске требуется создать по слайсу на всем свободном пространстве (объем их должен быть примерно равным), а уж эти слайсы побить на попарные (и равновеликие) разделы, которые после конкатенации составят ветви /var, /usr, /home и все, которые еще планируется (например, /usr/ports и /usr/ports/distfiles).
Разметку слайсов можно выполнить двумя способами - через sysinstall (BSD Installer в DragonFlyBSD) или вручную. С первым способом все понятно - однако он не всегда желателен (а иногда и не проходит). И потому впору вспомнить о наших упражнениях по ручной разметке диска в предыдущем параграфе - именно здесь гибкость fdisk и disklabel оказываются востребованными.
Для ручной разметки переходим в однопользовательский режим (в данном случае это не обязательно, но лучше взять за правило все действия, связанные с разметкой дисков, выполнять из него - чисто для страховки). Далее размечаем оба диска - первый в интерактивном режиме, командой
$ fdisk -i /dev/ad0
а второй - как единый слайс (напомню, что подвергаемые конкатенации диски желательно разнести на разные IDE-контроллеры)
$ fdisk -I /dev/ad2
Далее, вооружившись bsdlabel (или disklabel), запускаемой с опцией -e, калькулятором командной строки bc и, конечно же, man (8) bsdlabel, на первом (/dev/ad0s1) диске, в дополнение к имевшимся
a: 524288 0 4.2BSD 2048 16384 32776 b: 2074624 524288 swap c: 156301488 0 unused 0 0
дописываем строки, определяющие полуразделы под будущие файловые системы, например, /var, /usr и /home. В результате получаем:
d: 524288 2598912 4.2BSD 0 0 0 e: 10240000 3123200 4.2BSD 0 0 0 f: 142938288 13363200 4.2BSD 0 0 0
После этого обращаемся ко второму диску (/dev/ad2s1), на котором создаем парные к первому разделы под swap, /var, /usr и /home (того же размера, что и на первом диске), что в итоге дает:
b: 2074624 0 swap c: 156301312 0 unused 0 0 # "raw" part, don't edit d: 524288 2074624 4.2BSD 0 0 0 e: 10240000 2598912 4.2BSD 0 0 0 f: 142938112 12838912 4.2BSD 0 0 0
Теперь наступает время конкатенации партиций - и для этого имеется специальная утилита ccdconfig. Вооружась соответствующей man-страницей - man (8) ccdconfig, выясняем, что и эту процедуру можно проделать двумя разными способами. Правда, оба требуют перехода в однопользовательский режим - теперь уже обязательно, если мы не сделали этого ранее.
Первый способ - последовательный запуск ccdconfig для каждой пары сливаемых партиций примерно таким образом:
$ ccdconfig ccd0 128 none /dev/ad0s1d /dev/ad2s1d $ ccdconfig ccd1 128 none /dev/ad0s1e /dev/ad2s1e $ ccdconfig ccd1 128 none /dev/ad0s1f /dev/ad2s1f
Где ccd# - имя создаваемого RAID-устройства, 128 (для примера - это умолчальное значение) - размер (в Кбайт) chunk'ов, флаг none отменяет зеркалирование (то есть создает именно sripped-массив; чтобы сделать массив уровня 1, потребовалось бы указать флаг CCDF_MIRROR или его шестнадцатеричное значение - 004). Ну а аргументы понятны - это имена файлов партиций, которые подвергаются конкатенации.
В результате в каталоге /dev будут автоматически созданы новые устройства - /dev/ccd0, /dev/ccd1, /dev/ccd2 (речь идет о FreeBSD веnrи 5.X, использующей файловую систему устройств; в 4-й ее ветке и в DragonFlyBSD эти устройства потребовалось бы предварительно создать скриптом /dev/MAKEDEV или командой mknod), а в каталоге /etc возникнет конфигурационный файл ccd.config.
Второй способ - создать предварительно конфигурационный файл /etc/ccd.conf ( которому на самом деле можно дать произвольное имя и поместить где угодно) в текстовом редакторе, и описать в нем объединяемые примерно таким образом:
# ccd ileave flags component devices ccd0 128 none /dev/ad0s1d /dev/ad2s1d ccd1 128 none /dev/ad0s1e /dev/ad2s1e ccd2 128 none /dev/ad0s1f /dev/ad2s1f
После чего запустить ту же утилиту конфигурации следующим образом:
$ ccdconfig -C
в результате чего все необходимые сведения будут взяты из /etc/ccd.conf (если конфигу дали другое имя - следует явно указать его как аргумент с полным путем), устройства благополучно созданы.
Сбросить уже имеющиеся настройки ccd (если они почему-либо не устраивают) можно командой
$ ccdconfig -U
после чего они безболезненно переконфигурируются заново.
Дальнейшее обращение с конкатенированными массивами происходит точно также, как и с обычными партициями: то есть их нужно разметить на BSD-разделы, на которых создаются файловые системы, монтируемые в целевые каталоги. За одним исключением - прибегнуть к помощи sysinstall или BSD Installer теперь уже точно не удастся, так что вся надежда только на собственные руки.
Итак, для начала размечаем созданные массивы:
$ bsdlabel -w /dev/ccd0 auto $ bsdlabel -w /dev/ccd1 auto $ bsdlabel -w /dev/ccd2 auto
Что даст нам на каждом из них по партиции c, к использованию непригодной. И потому повторяем процедуру в ручном режиме:
$ bsdlabel -e /dev/ccd#
что, как мы помним, вызовет текстовый редактор для прямой модификации дисковой разметки. Копируем строку, описывающую партицию c, изменяем маркирующую ее литеру (например, на d) и тип раздела (с unused на 4.2BSD). Необходимости указывать размеры блока, фрагмента и прочего - нет, эти значения будут определены при создании файловой системы (о чем - в следующих параграфах).
После создания файловых систем их остается только смонтировать - сначала во временные каталоги типа /mnt/var, mnt/usr и /mnt/home, затем переместить в них содержимое одноименных кталогов из корня, и, наконец, прописать прописать монтирование конкатенированных разделов в /etc/fstab примерно таким образом:
/dev/ccd0e /var ufs rw,noatime /dev/ccd1e /usr ufs rw,noatime /dev/ccd2e /home ufs rw,noatime
После чего следует перезагрузка и радость от обретенных RAID'ов. Причем с точки зрения быстродействия радость эта будет вполне обоснованной: измерения показали прирост скорости на типичных файловых операциях для ccd-RAID составляет от 10 до 50% против одиночного диска.
Теперь остается сказать несколько слов об инструментарии для реализации технологии LVM, имеющей место быть только в Linux (пока?).
Для использования LVM требуется поддержка ядром системы. Это достигается включением двух опций. При использовании make menuconfig в секции Multi-device support нужно включить, во-первых, поддержку Multiple devices, во-вторых - Device Mapping (это в ядре 2.6.X, в ядрах 2.4.X это называлось Logical volume manager (LVM) support).
Далее, дисковое пространство (на одном или нескольких накопителях) следует разметить в виде разделов с идентификатором Linux LVM (8e в шестнадцатеричном исчилении).
И, естественно, потребуется софт для работы с LVM. Он входит в пакет lvm (lvm2), в составе которого - три группы утилит, предназначенных для работы с физическими томами (pv*), логическими группами (lg*) и логическими томами (lv*). Так, команда pvcreate создает физические тома, команда pvscan - сообщает об наличествующих, а команда pvdisplay выводит о них полную информацию. А тройки команд vgcreate, vgscan, vgdisplay и lvcreate, lvscan, lvdisplay проделывают то же для групп томов и логических томов, соответственно.
Как и положено уважающим себя Unix-программам, все компоненты пакета хорошо документированы, и с их опциями можно ознакомиться на стандартных man- и info-страницах. Вышеупомянутый LVM-HOWTO (http://tldp.org/HOWTO/LVM-HOWTO.html) содержит много информации по практическому применению этих команд (в том числе и душераздирающую историю о глупом Джо, не использовавшем LVM, и умной Джейн, без нее жизни себе не мыслившей).
Далее все требуемые действия могут быть расписаны по шагам. Первый из них - запуск команды
$ vgscan
которая отыщет все имеющиеся в наличии потенциальные физические тома, то есть разделы типа 8e и создаст необходимые файлы конфигурации - /etc/lvmtab и /etc/lvmtab.d, о чем любезно нас проинформирует.
Второй шаг - собственно превращение дискового раздела Linux LVM в физический том командой
$ pvcreate /dev/hda5
После этого командой pvscan можно проверить, что система думает о наших томах. В ответ она сообщит путь к каждому из файлов устройств физических томов, их объем и степень занятости (пока, разумеется, нулевую), а также состояние (на данном этапе - не активное).
Третий шаг - создание из физических томов логической группы (Volume Group). Для этого потребуется команда vgcreate с именем группы в качестве первого аргумента и имени файла устройства раздела - как аргумента второго.
Имя группы - произвольно, в путях к файлам устройств физических томов при использовании devfs должна применяться полная нотация (как это вывела команда pvscan). По умолчанию тома нарезаются на физические блоки - extent'ы размером 4 Мбайт. При желании иметь другой размер блока - это можно явно задать опцией -s ##m. Резонные люди рекомендует использовать extent'ы в 32 Мбайт. То есть требуемая команда будет иметь вид вроде
$ vgcreate -s 32m all /dev/ide/host0/bus0/target0/part5
В этом случае максимальный размер любого из будущих логических томов ограничивается фантастической (пока) величиной 2 терабайта. Если же остановиться на умолчальном extent'е, предел тома составил бы всего-навсего 256 Гбайт. Именно всего-навсего - согласитесь, ныне эта величина не кажется недостижимой.
Теперь можно выполнить команду pvscan, дабы убедиться в результате. Она, плюс к прежней информации, сообщит нам, что физические тома активированы и включены в группу имя рек.
А полную информацию о вновь созданной группе мы получим командой vgdisplay, которая, в числе прочего, сообщит нам имя группы, режим доступа к ней и ряд других данных:
--- Volume group --- VG Name all VG Access read/write VG Status available/resizable VG # 0 MAX LV 256 ...
MAX LV Size 2 TB Max PV 256 Cur PV 1 Act PV 1 VG Size 73 GB PE Size 32 MB Total PE 2336 ... VG UUID TiYr9D-5Ub5-ordV-Zcv6-A7Eg-AIqD-1ALFe6
Четвертый шаг - собственно создание логического тома или томов, по желанию. Это - некий аналог нарезания на разделы физического жесткого диска. И осуществляется он командой lvcreate, для которой в качестве опций нужно указать размер тома и его имя (-L и -n, соответственно), а аргументом - имя ранее созданной группы. Размер тома можно указывать в гигабайтах или в любых других *байтах. И очевидно из названия, что под логический том можно отвести как весь объем группы, так и ее часть - в последнем случае у нас останется место и для других томов. Например, для создания томов под обычно обособляемые файловые системы последовательность команд примет такой вид:
$ lvcreate -L 10G -n lvusr all && \ lvcreate -L 2G -n lvar all && \ lvcreate -L 2G -n lvopt all && \ lvcreate -L 55G -n lvhome all && \ lvcreate -L 2G -n lvtmp all
создаст нам тома под все намеченные к использованию файловые системы. Имена томов, разумеется, произвольны и даны просто в мнемонически удобном виде.
Замечу, что приведенной последовательностью команд создаются логические тома с линейным соответствием физических и логических extent'ов. Предписать использование схемы чередования (striped) можно дополнительной опцией -i. А опция -I [значение] задаст размер чередующих блоков (в килобайтах). Однако это имеет смысл только при наличии двух физических дисков (да еще, как неоднократно подчеркивалось ранее, на отдельных IDE-каналах).
Теперь выполним проверку: командой lvscan отыскиваем все новообразованные логические тома, узнаем пути к файлам соответствующих им устройств, их размеры и убеждаемся в том, что тома (прекрасный каламбур, господа?) активированы
lvscan -- ACTIVE "/dev/all/lvusr" [10 GB] lvscan -- ACTIVE "/dev/all/lvar" [2 GB] lvscan -- ACTIVE "/dev/all/lvopt" [2 GB] lvscan -- ACTIVE "/dev/all/lvhome" [55 GB] lvscan -- ACTIVE "/dev/all/lvtmp" [2 GB] lvscan -- 5 logical volumes with 71 GB total in 1 volume group lvscan -- 5 active logical volumes .
А командой
$ lvdisplay /dev/all/lv*
получаем о каждом томе всю информацию, которую в силах предоставить нам система, например:
$ lvdisplay /dev/all/lvhome --- Logical volume --- LV Name /dev/all/lvhome VG Name all LV Write Access read/write LV Status available LV # 4 # open 1 LV Size 55 GB Current LE 1760 Allocated LE 1760 Allocation next free Read ahead sectors 1024 Block device 58:3
Остается пятый, последний, шаг: создание на каждом логическом томе файловой системы и ее монтирование - но тут уж никакой специфики нет.
Выше был описан пример для случая организации логических томов на одном диске. На двух и более - ничуть не сложнее. Придется только повторить команду pvcreate должное число раз - для создания на каждом физических томов (Physical Volume):
$ pvcreate /dev/hda5 $ pvcreate /dev/hdc5 ...
А при объединении их в логическую группу - указать в качестве аргументов каждый из физических томов:
$ vgcreate имя_группы /dev/hda5 /dev/hdc5
При создании же собственно логического тома с помощью опций -i и -I можно попытаться повысить производительность дисковых операций: команда вроде
$ lvcreate -i 2 -I 8 -L 60G -n lvhome имя_группы
создаст схему соответствия stripped между физическими и логическими extent'ами, то есть иллюзию чередования записи на два физических диска блоками (chunks) по 8 Кбайт.
