Зачем использовать LVM? Создает больше границ (меньше свободы)

Использование LVM в целом позволяет использовать несколько функций. Всего пара:

• Расширение тома в один шаг и онлайн: lvextend --resize.
• Разбиение на разделы не требуется. Без LVM, как правило, изменение размера корневой файловой системы требует простоя и, возможно, редактирования таблиц разделов из другой системы.
• Снимки доступны всегда, даже без такой функции в системе хранения или гипервизоре.
• В экстремальных случаях может потребоваться том, поддерживаемый несколькими дисками (LUN). Редко в наши дни. Но с тем же успехом можно стандартизировать более гибкий LVM.

(Некоторые детали относятся к Linux LVM, но LVM в целом реализован во многих операционных системах. В UNIX AIX и HP-UX предшествуют Linux и имеют аналогичные LVM.)

Это конкретное распределение похоже на значения по умолчанию для такие дистрибутивы, как Red Hat, отражающие некоторые рекомендации, которые они давали в течение длительного времени.

Чтобы хранить пользовательские данные отдельно от системных данных, создайте специальный раздел в группе томов для каталога / home. Это позволит вам обновить или переустановить Red Hat Enterprise Linux без удаления файлов данных пользователя.

Да, пространство подкачки можно было бы разместить в более удобном файле. Я думаю, для этого нужны определенные файловые системы. Непосредственно на блочном уровне устройство работает независимо от файловой системы, и очевидно, что для обычных файлов места нет. Кроме того, вы можете переместить этот том пространства подкачки в быстрое менее надежное хранилище, например, на один локальный SSD.

Некоторые администраторы идут дальше и изолируют, например, /var на собственном объеме и /tmp на tmpfs. Таким образом, файлы журналов и тому подобное не будут заполнять пространство, необходимое для программного обеспечения в /usr.

Лично при отсутствии требований к размеру я бы начал /home офф поменьше скажем 20 гб. Таким образом, в VG остается 70 ГБ свободного места на все нужды следующего lvextend. Это тоже предлагалось долгое время. Я подозреваю, что это не автоматическое разделение по умолчанию, потому что пользовательские данные имеют тенденцию неограниченно расти, и они хотят использовать пространство на случай, если планирование емкости никогда не будет пересмотрено.

Оставьте лишнюю емкость нераспределенной и сразу же назначьте емкость хранилища тем разделам, которые вам нужны. Вы можете выделить свободное пространство в любое время для удовлетворения потребностей по мере их возникновения.

Во многих случаях одиночный раздел или его отсутствие не являются вредными, особенно в виртуализированной среде, где вы можете легко увеличить основной диск и корневую файловую систему, если и когда вам не хватит места.

Пока ты не сможешь ...

Затем вы на собственном горьком опыте узнаете, что жесткое разбиение на разделы - это выбор дизайна, на котором вы застряли на протяжении всего срока службы вашего сервера.
_{(Не полностью, но для большинства решений потребуются простои и / или перерывы в обслуживании.)}

Если у вас только крупный рогатый скот: это не проблема, ваши серверы и так недолговечны. Если у вас больше домашних животных, чем вы бы хотели признать ...

Накладные расходы на производительность / штрафы, которые вы платите за использование LVM, незначительны, и даже сейчас вы не видите немедленной необходимости LVM потенциально спасет ваш бекон в будущем, когда LVM позволит вам выполнять онлайн-изменения в вашем хранилище, которые в противном случае были бы либо явными невозможно или, по крайней мере, потребует (значительного) простоя.

Ответ таков: если вы не можете определить какие-либо операционные причины для использования LVM, то нет причин для его использования, что в вашем сценарии гипервизора и сети хранения данных легко отклонить. но LVM не является протоколом, таким как smb или iscsi, и не файловой системой, такой как ext4 или ntfs, это также не массив JBOD или какой-либо RAID, это не тип диска, такой как SSD или SAS, это не поставщик хранилища, такой как VMware datastore или Ceph - так зачем использовать LVM? - независимо от всего этого представлять ОС логические тома.

Некоторые дистрибутивы по умолчанию настраивают свое разделение с помощью LVM / device mapper по умолчанию. Как указывалось ранее, накладные расходы при использовании LVM небольшие (хотя и не совсем нулевые) и повышают гибкость, так что это неплохой выбор.

Что касается отдельных файловых систем: отдельный /home к / часто рационализируется как метод квотирования бедняков. Держа их отдельно, наполняя /home не отображает инструмент, которому нужно только создавать файлы в /tmp (лайк sort) не может делать свою работу. Еще раз, некоторые инструменты разметки (Ubuntu?) Направят вас к такому стилю настройки.

Может, предыдущий админ просто придерживался настроек по умолчанию? Если у вас другие потребности и вы уже начинаете заново, то, конечно, вы можете сделать другой выбор. Однако, если система в порядке и ей не хватает места (20 ГБ для root может означать, что у вас осталось более 50% свободного места или может быть недостаточно в зависимости от ситуации), я сомневаюсь, что стоит потратить все усилия, чтобы разорвать все это и начать снова, просто чтобы переключиться.

В соответствии с традиционной моделью разбиения на разделы чрезвычайно сложно изменить размер или переместить раздел в работающей системе. Обычно это требует отключения или создает риск потери данных. LVM решает эти проблемы.

В крайнем случае LVM можно использовать для замены отказавшего диска в работающей системе.

LVM также упрощает реализацию RAID, что может быть легко выполнено для каждого логического тома.

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

Существуют аргументы за и против использования разных разделов для разных подкаталогов. Я сделал и то, и другое. Одна из возникающих проблем - рост файловой системы за пределы емкости ее раздела. Хотя в некоторых случаях существуют несколько безопасные варианты, LVM обеспечивает безопасный путь к расширению разделов (логических томов) в работающей системе.

Есть много вариантов обмена, но обычно вы хотите иметь возможность быстро менять местами. К счастью, современное управление памятью меньше полагается на процессы подкачки и больше на разбиение на страницы. Доступ к файлу подкачки обычно требует больших затрат, чем доступ к разделу подкачки или логическому тому. Это менее важно для систем с достаточным объемом памяти, чтобы избежать активного использования пространства подкачки.

Хотя в некоторых случаях LVM может увеличить накладные расходы при поиске местоположения блока на диске, непрерывный логический том на одном диске должен иметь такие же накладные расходы, как и раздел. В случаях, когда LVM увеличивает накладные расходы, другие компромиссы могут обеспечить лучшую производительность файловой системы. Понимание компромиссов должно быть частью процесса планирования использования более сложной конфигурации LVM.