зачем изменять размер PV, а не добавлять новый PV?
Вы можете комбинировать --new-instance (который запускает новый экземпляр во всех случаях) с -P, который позволяет выбрать другой профиль: используйте его один раз для создания чистого профиля, затем назовите его в командной строке, и Firefox запустит новый экземпляр с этим профилем.
Вывод: с чисто технической точки зрения это не имеет большого значения, но изменение размера лучше. Как только вы добавите практические аспекты, добавление нового раздела станет явным победителем.
С чисто технической точки зрения у новых PV есть несколько недостатков:
- Вы получаете еще одну копию метаданных LVM, это требует некоторого дискового пространства. Если вы часто выполняете операции LVM, это также приводит к усилению записи (поскольку метаданные зеркалируются для всех PV)
- Может оставаться пустое место для выравнивания
- Немного увеличивается количество метаданных LVM (на копию) для хранения Информация о новом PV.
- Если вы создаете LV, который охватывает оба PV, он не является непрерывным (из-за дополнительных метаданных и любых пробелов, оставленных для выравнивания). Так, например, если вы использовали этот LV для больших последовательных операций чтения/записи, теперь там есть поиск.
С практической точки зрения, ни один из них не имеет значения для любого разумного количества PV. В первую очередь важны дополнительные копии метаданных, но есть опция LVM, позволяющая хранить меньше копий (VG -- metadatacopies или PV -- metadataignore).
Кроме того, продолжая практическую точку зрения, удаление и повторное создание раздела с гораздо большей вероятностью пострадает от ошибки администратора (опечатка и т. д.), чем создание нового раздела из-за лучших инструментов для последнего. И любые возникающие ошибки администратора, вероятно, будут гораздо более разрушительными для изменения размера (поскольку ваши данные находятся в разделе с измененным размером, а в новом разделе нет данных). Это еще хуже, когда у вас есть несколько слоев; например, mdraid ниже LVM. В зависимости от вашей опции -e, суперблоки могут быть в конце массива — это весело, когда вы изменяете размер раздела.
Есть одно исключение, которое приходит на ум: если по какой-либо причине вы не можете создать новый раздел. Например, возможно, вы используете таблицы разделов DOS и уже использовали все четыре основных раздела (без создания расширенного раздела). Тогда у тебя нет выбора.
Масштабирование хранилища в горизонтальном направлении, как вы предлагаете, продолжая добавлять больше физических томов в ту же группу VG для увеличения хранилища вашей виртуальной машины, станет некрасивым.
Допустим, вам нужно увеличить пространство на виртуальной машине в 10 раз -вы собираетесь добавить новый PV в виртуальную группу в 10 раз? В конечном итоге к вашим виртуальным машинам будет подключено огромное количество виртуальных дисков и виртуальных томов.
И что происходит, когда вы выполняете lvextendи resize2fsкаждый раз, когда добавляете PV в VG, чтобы использовать дополнительное пространство? Ваши LV и файловые системы, которые на них живут , будут охватывать несколько PV. Если вы выполните pvdisplay -m, вы увидите, что ваши LV используют экстенты из разных PV.
Чем чрезмерно сложна система, тем больше вероятность того, что она выйдет из строя каким-нибудь странным и неожиданным образом.
Этонеговорить " Не более ОДНОГО PV (виртуального диска )на ВМ "! Использование одного PVдля каждой VG , т.е.:vg_systemи vg_dataбыло бы аккуратной организацией, абстрагирующей данные в отдельную кучу от ОС. Я бы только посоветовал избегать использования нескольких PV дляSAMEVG на ваших виртуальных машинах.
