LVM: производительность.

Как минимум у тебя появится лишняя (ненужная) сущность в виде еще одного RAID'а, на который ядро будет тоже тратить некую порцию ресурсов. Какой смысл держать диск полностью неразмеченным?

sda5, sdb5

Тогда уж sda4 и sdb4

Вопрос второй, для чего на одной системе могут понадобиться разные Volumе Group?

У меня, например, разные VG находятся на разных группах дисков - одна группа под системные разделы и сервисы, другая - под файлоархив. С разными группами я могу быть уверен, что при создании нового LV он будет использовать только свою группу дисков и не будет использовать для какого-нибудь системного раздела экстенты с дисков под файлопомойку.

> я могу быть уверен, что при создании нового LV он будет использовать только свою группу дисков

При вызове lvcreate можно указать, на каких PV («группах дисков») в вашей терминологии будет располагаться создаваемый том, так что необходимости в разных VG на самом деле нет.

По производительности не скажу, не сравнивал.

Но, ИМХО,

1) несколько PV на одном жёстком диске - это черезж

2) лучше бы использовать для физических дисков одну общую группу томов - мало ли когда потребуется расширить ФС ( а понадобится точно ;) )

>Тогда уж sda4 и sdb4

Не угадал, в extended разделе нумерация идёт с 5

mdraid умеет ресайз.

> Какой смысл держать диск полностью неразмеченным?
1. Например может понадобиться дополнительный раздел вне LVM.
2. Зеркало делать sync быстрее будет.
3. Данные которые будут ближе к началу диска будут с него быстрее читаться.

Тогда уж sda4 и sdb4

В планах именно расширенный раздел, так как в случае необходимости планируется добавлять не сразу все 500Гб, а оставить «про запас».

С разными группами я могу быть уверен, что при создании нового LV он будет использовать только свою группу дисков

По-моему всегда при создании LV можно указать где его располагать.

> 1) несколько PV на одном жёстком диске - это черезж
Почему?

2) лучше бы использовать для физических дисков одну общую группу томов - мало ли когда потребуется расширить ФС ( а понадобится точно ;) )

Тоже так думаю, но на некоторых серверах, которые мне попадались используются несколько VG, вот и пытаюсь понять для чего.

Хм, интересно, только вот я пользуюсь mdadm, что он такое умеет не слышал.

>Почему?

Встречный вопрос: а зачем? Keep it simple. В 2-х vg на одном винте я вижу только неоправданное усложнение. Если сервер 1, ну максимум 10, ещё можно. Если больше - повесишься уже на документировании такого изврата, не говоря уже о решении инцидентов.

Между 2-мя VG ты никак не передашь экстенты. Потребуется увеличить ФС, а всё место на другой VG. ССЗБ.

Если дисков много - иногда имеет смысл разбить их по разным VG (см. дальше), но один диск - один PV

Тоже так думаю, но на некоторых серверах, которые мне попадались используются несколько VG, вот и пытаюсь понять для чего.

Я их каждый день вижу, но там оптика и диски выдаются с массива. При этом массив берёт на себя большую часть функций, а LVM остаётся только склеивать диски в одну ФС. Например: X дисков по Y Gb, часть из них идёт под одну базу (одна VG), часть под другую (другая VG). Или - одна VG под датафайлы, другая VG - под арклоги и т.п. (менее удобно).

НО при этом всё равно один диск - один PV

>НО при этом всё равно один диск - один PV Выше вы говорили про два VG на одном винте. Но почему черезж, когда два PV на одном винте, например из sda3 и sda5, и они добавлены в один VG.

>> Хм, интересно, только вот я пользуюсь mdadm, что он такое умеет не слышал.

man mdadm | festival

и услышишь.

Кроме шуток, я недавно как раз увеличил массив с домашним каталогом онлайн, никаких проблем. И да, mdadm — юзерспейсная часть mdraid.

Ты можешь ответить - зачем?

А какой уровень рейда у тебя был?

>Например может понадобиться дополнительный раздел вне LVM

Зачем? Я за много лет с такой проблемой ни разу не сталкивался.

Зеркало. Работает ли с другими, не знаю.

Прозреваю альтернативные ОС :)

альтернативной ОС не нужен дополнительный PV, она на LVM вообще смотрит с нездоровым интересом и предлагает отформатировать :)

А изучать другие ОС лучше в виртуалке, для которой диск нарезать как раз в VG

Зеркало

Значит для того чтобы увеличить массив ты заменял винты, верно? А потом grow делал.

А с lvm можно просто добавить сторадж и «растянуть» логический диск. В плане гибкости управления томами lvm сильно впереди потому что он создавался с прицелом на это. Я поэтому рекомендовал бы ТС lvm(может даже поверх mdadm для надёжности).

>> Значит для того чтобы увеличить массив ты заменял винты, верно?

Нет. Для удобства массив изначально создавался размером в половину подлежащих разделов (200 GiB из 400), а потом я просто прибавил 50 GiB, когда понадобилось место.

А потом grow делал.

Угу, с опцией -z.

> При вызове lvcreate можно указать, на каких PV («группах дисков») в вашей терминологии будет располагаться создаваемый том, так что необходимости в разных VG на самом деле нет.

Ага, таки да, спасибо.

PV («группах дисков») в вашей терминологии

Тут PV является RAID'ом, состоящий из определенных дисков - я в этом плане имел в виду )

Правильный ответ на 2 поста ниже твоего.

Но все равно не вижу смысла городить 100500 разделов при наличии LVM

>Правильный ответ на 2 поста ниже твоего.

Т.е. ты утверждаешь, что разделы в extended будут нумероваться с 4? Чушь. Если ты намекаешь, что нужно использовать lvm и mdadm, я этого и не думал отрицать. Так о чём будем спорить? ;)

Я утверждаю, что изначально речь шла про один дополнительный раздел, а в таком случае логичнее использовать 4-й primary-раздел, а не создавать вместо него цепочку «контейнер->раздел». А в упомянутом посте ТС раскрыл тему создания еще 100500 ненужных физических разделов - тут да, без extended не обойтись.

Коллеги, то есть по вашему мнению, так заморачиваться из-за:
1. Например может понадобиться дополнительный раздел вне LVM.
2. Зеркало делать sync быстрее будет.
3. Данные которые будут ближе к началу диска будут с него быстрее читаться.
не стоит? И ни у кого не было ситуации когда жалели что ничего про запас не оставляли или что все го лишь один VG?
Как я понимаю, общая тенденция такова, что всё что-есть отдают одной VG ещё на этапе запуска, без всяких «про запас»?

man mdadm | festival

Положим размер md1 при необходимости я увеличу. А как сообщить VG, что PV md1 в её составе увеличился?
З.Ы. Сорри за нубовский вопрос, но никогда не увеличивал таким образом размер VG (увеличением размера PV).

>> А как сообщить VG, что PV md1 в её составе увеличился?

Группа это всего лишь группа. pvresize достаточно.

> 2. Зеркало делать sync быстрее будет.

«Зеркало» - RAID, что ли? С чего бы? Он про LVM ничего не знает

> И ни у кого не было ситуации когда жалели что ничего про запас не оставляли или что все го лишь один VG?

Наоборот - была ситуация, когда пришлось жалеть что несколько VG, а не одна :-)

>«Зеркало» - RAID, что ли? С чего бы? Он про LVM ничего не знает Есть разница синхронизировать 500Гб или 1ТБ.

> Как я понимаю, общая тенденция такова, что всё что-есть отдают одной VG ещё на этапе запуска, без всяких «про запас»?

Другую группу томов (VG) имеет смысл заводить на отдельных физических дисках. Будешь еще 2 ставить - на них заведешь другую VG, если нужно....

Речь больше не о другой группе, а весь ли 1Тб отдать дисковой группе, когда на первый взгляд не нужно будет больше 500Гб или оставить 500Гб про запас, а в случае необходимости группе добавить ещё. Не понятно на сколько производительность LVM падает, когда в VG не один PV, а два PV оба из которых расположены на одном физическом диске.