Назад | Перейти на главную страницу

Опасности и предостережения LVM

Недавно я начал использовать LVM на некоторых серверах для жестких дисков размером более 1 ТБ. Они полезны, расширяемы и довольно просты в установке. Однако мне не удалось найти никаких данных об опасностях и предостережениях LVM.

Каковы недостатки использования LVM?

Резюме

Риски использования LVM:

  • Уязвим к записи проблем с кешированием с гипервизором SSD или виртуальной машины
  • Сложнее восстановить данные из-за более сложных структур на диске
  • Труднее правильно изменить размер файловой системы
  • Снимки сложно использовать, они медленные и содержат ошибки
  • Требуются определенные навыки для правильной настройки с учетом этих проблем

Первые две проблемы LVM сочетаются: если кэширование записи работает некорректно и у вас есть потеря питания (например, сбой блока питания или ИБП), вам вполне может потребоваться восстановление из резервной копии, что означает значительное время простоя. Основной причиной использования LVM является более высокое время безотказной работы (при добавлении дисков, изменении размера файловых систем и т. Д.), Но важно правильно настроить кэширование записи, чтобы LVM фактически не сокращал время безотказной работы.

- Обновлено декабрь 2019 г .: незначительное обновление btrfs и ZFS в качестве альтернативы моментальным снимкам LVM.

Снижение рисков

LVM по-прежнему может хорошо работать, если вы:

  • Правильно настройте кэширование записи в гипервизоре, ядре и твердотельных накопителях
  • Избегайте снимков LVM
  • Используйте последние версии LVM для изменения размера файловых систем
  • Хорошие резервные копии

подробности

Я довольно много исследовал это в прошлом, испытав некоторую потерю данных, связанную с LVM. Основные риски и проблемы LVM, о которых я знаю:

Уязвимость к кэшированию записи на жесткий диск из-за гипервизоров виртуальных машин, кэширования диска или старых ядер Linux., и затрудняет восстановление данных из-за более сложных структур на диске - подробности см. ниже. Я видел, как полные настройки LVM на нескольких дисках были повреждены без всяких шансов на восстановление, а LVM плюс кэширование записи на жесткий диск - опасная комбинация.

  • Кэширование записи и изменение порядка записи на жестком диске важен для хорошей производительности, но может не сбрасывать блоки на диск правильно из-за гипервизоров виртуальных машин, кэширования записи на жесткий диск, старых ядер Linux и т. д.
  • Пишите барьеры означают, что ядро ​​гарантирует, что оно завершит определенные операции записи на диск до «барьерной» записи на диск, чтобы файловые системы и RAID могли восстановиться в случае внезапного отключения питания или сбоя. Такие барьеры могут использовать Операция FUA (Force Unit Access) для немедленной записи определенных блоков на диск, что более эффективно, чем полная очистка кеша. Барьеры можно сочетать с эффективными отмечен/родной организация очереди команд (выдача нескольких запросов ввода-вывода одновременно), позволяющая жесткому диску выполнять интеллектуальное изменение порядка записи без увеличения риска потери данных.
  • Гипервизоры ВМ могут быть похожие проблемы: запуск LVM в гостевой системе Linux поверх гипервизора виртуальной машины, такого как VMware, Xen, KVM, Hyper-V или VirtualBox могут создавать похожие проблемы в ядро ​​без барьеров для записи из-за кэширования и изменения порядка записи. Внимательно проверьте документацию к гипервизору, чтобы узнать о параметрах «сброса на диск» или кэширования со сквозной записью (присутствует в KVM, VMware, Xen, VirtualBox и другие) - и протестируйте его со своей настройкой. Некоторые гипервизоры, такие как VirtualBox, имеют настройка по умолчанию который игнорирует любую очистку диска от гостя.
  • Корпоративные серверы с LVM всегда должны использовать RAID-контроллер с батарейным питанием и отключите кэширование записи на жесткий диск (в контроллере есть кэш записи с резервным питанием от батареи, который работает быстро и безопасно) - см. этот комментарий автором эта запись XFS FAQ. Также может быть безопасно отключить барьеры записи в ядре, но рекомендуется тестирование.
  • Если у вас нет RAID-контроллера с батарейным питанием, отключение кэширования записи на жесткий диск значительно замедлит запись, но сделает LVM безопасным. Вы также должны использовать эквивалент ext3 data=ordered вариант (или data=journal для дополнительной безопасности), плюс barrier=1 чтобы гарантировать, что кеширование ядра не влияет на целостность. (Или используйте ext4, который по умолчанию включает барьеры.) Это самый простой вариант, обеспечивающий хорошую целостность данных за счет снижения производительности. (Linux изменена опция ext3 по умолчанию к более опасным data=writeback некоторое время назад, поэтому не полагайтесь на настройки по умолчанию для FS.)
  • Чтобы отключить кеширование записи на жесткий диск: Добавить hdparm -q -W0 /dev/sdX для всех дисков в /etc/rc.local (для SATA) или используйте sdparm для SCSI / SAS. Однако, по мнению эта запись в FAQ по XFS (что очень хорошо по этой теме), диск SATA может забыть этот параметр после восстановления ошибки диска - поэтому вам следует использовать SCSI / SAS, или, если вы должны использовать SATA, поместите команду hdparm в задание cron работает примерно каждую минуту.
  • Чтобы оставить включенным кэширование записи на SSD / жесткий диск для лучшей производительности: это сложная область - см. раздел ниже.
  • Если вы используете Диски расширенного формата т.е. физические сектора размером 4 КБ, см. ниже - при отключении кэширования записи могут возникнуть другие проблемы.
  • UPS критически важен как для предприятия, так и для SOHO, но недостаточен для обеспечения безопасности LVM: все, что вызывает серьезный сбой или потерю питания (например, отказ ИБП, сбой блока питания или разряд батареи ноутбука), может привести к потере данных в кэшах жесткого диска.
  • Очень старые ядра Linux (2.6.x с 2009 г.): В очень старых версиях ядра 2.6.32 и более ранних (2.6.31 имеет некоторую поддержку, пока 2.6.33 работает для всех типов целевых устройств) - RHEL 6 использует 2.6.32 с множеством патчей. Если эти старые ядра 2.6 не исправлены для устранения этих проблем, большой объем метаданных FS (включая журналы) может быть потерян из-за жесткого сбоя, который оставляет данные в буферах записи жестких дисков (скажем, 32 МБ на диск для обычных дисков SATA). Потеря 32 МБ последних записанных метаданных FS и данных журнала, которые, по мнению ядра, уже находятся на диске, обычно означает значительное повреждение файловой системы и, следовательно, потерю данных.
  • Резюме: Вы должны позаботиться о файловой системе, RAID, гипервизоре виртуальной машины и настройке жесткого диска / SSD, используемых с LVM. У вас должны быть очень хорошие резервные копии, если вы используете LVM, и обязательно сделайте резервную копию метаданных LVM, настройки физического раздела, MBR и загрузочных секторов тома. Также рекомендуется использовать диски SCSI / SAS, поскольку они с меньшей вероятностью лгут о том, как они выполняют кэширование записи - для использования дисков SATA требуется больше осторожности.

Сохранение кэширования записи включенным для производительности (и справиться с лежачими дисками)

Более сложный, но эффективный вариант - оставить включенным кэширование записи SSD / жесткого диска и полагаться на барьеры записи ядра, работающие с LVM в ядре 2.6.33+ (дважды проверьте, посмотрев «барьерные» сообщения в журналах).

Вы также должны убедиться, что настройка RAID, настройка гипервизора виртуальной машины и файловая система использует барьеры записи (т.е. требует, чтобы диск сбрасывал ожидающие записи до и после записи ключевых метаданных / журнала). XFS по умолчанию использует барьеры, а ext3 - нет., поэтому с ext3 вы должны использовать barrier=1 в параметрах монтирования и по-прежнему используйте data=ordered или data=journal как указано выше.

SSD проблематичны, поскольку использование кеша записи критично для срока службы SSD. Лучше всего использовать SSD с суперконденсатором (чтобы включить очистку кеша при сбое питания и, следовательно, включить обратную запись в кеш, а не сквозную запись).

Расширенный формат настройка диска - кэширование записи, выравнивание, RAID, GPT

  • С более новой Диски расширенного формата которые используют физические сектора размером 4 КиБ, может быть важно оставить включенным кэширование записи на диски, поскольку большинство таких дисков в настоящее время имитируют 512-байтовые логические сектора («Эмуляция 512»), а некоторые даже утверждают, что имеют 512-байтовые физические секторы, хотя на самом деле используют 4 КиБ.
  • Отключение кеша записи диска расширенного формата может вызвать очень большое влияние на производительность, если приложение / ядро ​​выполняет запись размером 512 байт, поскольку такие диски полагаются на кэш для накопления 8 x 512-байтовых операций записи перед выполнением одной физической записи размером 4 КиБ. написать. Рекомендуется тестирование, чтобы подтвердить любое влияние, если вы отключите кеш.
  • Выравнивание LV на границе 4 КиБ важен для производительности, но должен происходить автоматически, пока базовые разделы для PV выровнены, поскольку физические экстенты LVM (PE) по умолчанию составляют 4 МБ. Здесь необходимо учитывать RAID - это Страница настройки LVM и программного RAID предлагает поместить суперблок RAID в конец тома и (при необходимости) использовать опцию на pvcreate чтобы выровнять PV. Эта цепочка рассылки LVM указывает на работу, проделанную в ядрах в течение 2011 года, и на проблему частичной записи блоков при смешивании дисков с секторами размером 512 байт и 4 КиБ в одном LV.
  • Разделение GPT с помощью расширенного формата требует осторожности, особенно для загрузочных и корневых дисков, чтобы гарантировать, что первый раздел LVM (PV) начинается на границе 4 КиБ.

Сложнее восстановить данные из-за более сложных структур на диске:

  • Любое восстановление данных LVM, необходимое после серьезного сбоя или потери питания (из-за неправильного кэширования записи), в лучшем случае является ручным процессом, потому что, по-видимому, нет подходящих инструментов. LVM хорошо выполняет резервное копирование своих метаданных в /etc/lvm, который может помочь восстановить базовую структуру LV, VG и PV, но не поможет с потерянными метаданными файловой системы.
  • Следовательно, вероятно, потребуется полное восстановление из резервной копии. Это приводит к гораздо большему времени простоя, чем быстрый журнал fsck, когда LVM не используется, и данные, записанные с момента последней резервной копии, будут потеряны.
  • TestDisk, ext3grep, ext3undel и другие инструменты могут восстанавливать разделы и файлы с дисков без LVM, но напрямую не поддерживают восстановление данных LVM. TestDisk может обнаружить, что потерянный физический раздел содержит LVM PV, но ни один из этих инструментов не распознает логические тома LVM. Файл резьба инструменты, такие как PhotoRec и многие другие будут работать, поскольку они обходят файловую систему для повторной сборки файлов из блоков данных, но это последний низкоуровневый подход для ценных данных, который хуже работает с фрагментированными файлами.
  • В некоторых случаях восстановление LVM вручную возможно, но это сложно и требует много времени - см. этот пример и этот, этот, и этот как восстановить.

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

  • Обновить: Более свежие версии lvextend поддержать -r (--resizefs) вариант - если он доступен, это более безопасный и быстрый способ изменить размер LV и файловой системы, особенно если вы уменьшаете размер файловой системы, и вы можете пропустить этот раздел.

  • Большинство руководств по изменению размера FS на основе LVM не учитывают тот факт, что FS должна быть несколько меньше, чем размер LV: подробное объяснение здесь. При сжатии файловой системы вам нужно будет указать новый размер в инструменте изменения размера FS, например resize2fs для ext3 и для lvextend или lvreduce. Без особой осторожности размеры могут немного отличаться из-за разницы между 1 ГБ (10 ^ 9) и 1 ГБ. ГиБ (2 ^ 30), или то, как различные инструменты округляют размер вверх или вниз.

  • Если вы не выполните вычисления в точности (или используете некоторые дополнительные шаги помимо наиболее очевидных), вы можете получить FS, слишком большую для LV. Все будет хорошо в течение месяцев или лет, пока вы полностью не заполните FS, после чего вы получите серьезное повреждение - и, если вы не знаете об этой проблеме, трудно понять, почему, поскольку к тому времени у вас также могут быть реальные ошибки диска. что омрачает ситуацию. (Возможно, эта проблема влияет только на уменьшение размера файловых систем - однако ясно, что изменение размера файловых систем в любом направлении действительно увеличивает риск потери данных, возможно, из-за ошибки пользователя.)

  • Кажется, что размер LV должен быть больше, чем размер FS, на 2 x размер физического экстента (PE) LVM, но подробности см. По ссылке выше, поскольку источник для этого не является авторитетным. Часто достаточно 8 МБ, но может быть лучше разрешить больше, например 100 МиБ или 1 ГиБ, на всякий случай. Чтобы проверить размер PE и размер вашего логического тома + FS с использованием блоков 4 KiB = 4096 байтов:

    Показывает размер PE в КиБ:
    vgdisplay --units k myVGname | grep "PE Size"

    Размер всех LV:
    lvs --units 4096b

    Размер (ext3) FS, предполагает размер блока 4 KiB FS:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Напротив, установка без LVM делает изменение размера FS очень надежным и простым в использовании. Gparted и измените размер требуемых файловых систем, тогда он сделает все за вас. На серверах вы можете использовать parted из оболочки.

  • Часто лучше использовать Gparted Live CD или Разделенная магия, поскольку у них есть недавнее и часто более безошибочное Gparted & ядро, чем версия дистрибутива - однажды я потерял всю FS из-за того, что Gparted дистрибутива не обновлял разделы должным образом в работающем ядре. Если вы используете Gparted дистрибутива, обязательно перезагрузитесь сразу после смены разделов, чтобы вид ядра был правильным.

Снимки сложно использовать, они медленные и содержат ошибки - если в моментальном снимке заканчивается предварительно выделенное пространство, он автоматически упал. Каждый моментальный снимок данного LV представляет собой дельту по отношению к этому LV (не по сравнению с предыдущими снимками), что может потребовать много места при создании моментальных снимков файловых систем со значительной активностью записи (каждый моментальный снимок больше предыдущего). Безопасно создать снимок LV того же размера, что и исходный LV, так как в этом случае никогда не кончится свободное пространство.

Снимки также могут быть очень медленными (то есть от 3 до 6 раз медленнее, чем без LVM для эти тесты MySQL) - видеть этот ответ, охватывающий различные проблемы со снимками. Отчасти медлительность объясняется тем, что снимки требуют множества синхронных записей.

В снимках есть несколько серьезных ошибок, например в некоторых случаях они могут сделать загрузку очень медленной или привести к полному сбою загрузки (поскольку время ожидания ядра истекло ожидание корневой FS, когда это снимок LVM [исправлено в Debian initramfs-tools обновление, март 2015 г.]).

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

Альтернативные снимки - файловые системы и гипервизоры ВМ

Снимки ВМ / облака:

  • Если вы используете гипервизор виртуальной машины или облачного провайдера IaaS (например, VMware, VirtualBox или Amazon EC2 / EBS), их моментальные снимки часто являются гораздо лучшей альтернативой моментальным снимкам LVM. Вы можете довольно легко сделать снимок для резервного копирования (но перед этим подумайте о замораживании FS).

Снимки файловой системы:

  • Снимки на уровне файловой системы с ZFS или btrfs просты в использовании и, как правило, лучше, чем LVM, если вы работаете на «голом железе» (но ZFS кажется намного более зрелым, просто более хлопотно установить):

  • ZFS: теперь есть реализация ZFS в ядре, который используется уже несколько лет, и ZFS, похоже, получает все большее распространение. Ubuntu теперь имеет ZFS как вариант `` из коробки '', включая экспериментальную ZFS в корневом каталоге в 19.10.

  • btrfs: все еще не готов к использованию в производстве (даже на openSUSE который отправляет его по умолчанию и имеет команду, посвященную btrfs), тогда как RHEL прекратил его поддерживать). btrfs теперь имеет инструмент fsck (FAQ), но FAQ рекомендует вам проконсультироваться с разработчиком, если вам нужно fsck сломанной файловой системы.

Снимки для онлайн-резервного копирования и fsck

Снимки можно использовать для обеспечения согласованного источник для резервных копий, при условии, что вы будете осторожны с выделенным пространством (в идеале снимок имеет тот же размер, что и резервный LV). Отличный rsnapshot (начиная с 1.3.1) даже управляет созданием / удалением моментальных снимков LVM - см. это HOWTO по rsnapshot с использованием LVM. Однако обратите внимание на общие проблемы со снимками и то, что снимок не следует рассматривать как резервную копию.

Вы также можете использовать моментальные снимки LVM для онлайн-fsck: сделать снимок LV и выполнить fsck снимок, при этом по-прежнему используя основную FS без снимка - описано здесь - однако это не совсем простой так что лучше использовать e2croncheck так как описанный Тедом Ц'о, сопровождающий ext3.

Вам следует "заморозить" файловую систему временно при создании снимка - некоторые файловые системы, такие как ext3 и XFS, будут сделать это автоматически когда LVM создает снимок.

Выводы

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

LVM требует особой осторожности при настройке кэширования записи из-за гипервизоров виртуальных машин, кэширования записи на жесткий диск / SSD и т. Д. - но то же самое относится и к использованию Linux в качестве сервера БД. Отсутствие поддержки со стороны большинства инструментов (gparted включая расчеты критического размера, и testdisk и т. д.) усложняет использование, чем должно быть.

При использовании LVM будьте очень осторожны со снимками: используйте снимки виртуальной машины / облака, если это возможно, или исследуйте ZFS / btrfs, чтобы полностью избежать LVM - вы можете обнаружить, что ZFS или btrfs являются достаточно зрелыми по сравнению с LVM со снимками.

Итог: если вы не знаете о проблемах, перечисленных выше, и о том, как их решать, лучше не использовать LVM.

Я [+1] этот пост, и, по крайней мере, я думаю, что большинство проблем действительно существуют. Видел их при запуске нескольких 100 серверов и нескольких 100 ТБ данных. Для меня LVM2 в Linux кажется кому-то «умной идеей». Как и некоторые из них, они иногда оказываются «не умными». Т.е. отсутствие строго разделенных состояний ядра и пользовательского пространства (lvmtab), возможно, было бы разумно избавиться от этого, потому что могут быть проблемы с повреждением (если вы неправильно понимаете код)

Ну просто было это разделение по причине - различия проявляются с обработкой потери PV и онлайн-повторной активацией VG с отсутствующими PV, чтобы вернуть их в игру. состояние обработки недостаточно хорошее. И даже не заставляйте меня говорить об обнаружении потери кворума (ха-ха) или обработке состояния (если я удалю диск, он не будет отмечен как недоступный. Это даже не иметь чертов столбец статуса)

Re: стабильность pvmove... почему

потеря данных pvmove

такая статья в моем блоге, хммм? Только сейчас я смотрю на диск, на котором физические данные lvm все еще находятся в состоянии из mid-pvmove. Я думаю, были некоторые утечки памяти, и общая идея о том, что копирование данных живых блоков из пользовательского пространства - это хорошо, просто грустна. Хорошая цитата из списка lvm: "похоже, что vgreduce --missing не обрабатывает pvmove" Фактически означает, что если диск отсоединяется во время pvmove, тогда инструмент управления lvm изменяется с lvm на vi. Да, также была ошибка, из-за которой pvmove продолжается после ошибки чтения / записи блока и фактически больше не записывает данные на целевое устройство. Какого черта?

Re: Снимки CoW выполняется небезопасно, путем обновления НОВЫХ данных в области lv снимка и последующего объединения после удаления снимка. Это означает, что у вас есть сильные всплески ввода-вывода во время окончательного слияния новых данных с исходным LV и, что более важно, у вас, конечно, также гораздо более высокий риск повреждения данных, потому что моментальный снимок не будет сломан, когда вы нажмете стена, но оригинал.

Преимущество заключается в производительности: выполнение 1 записи вместо 3. Выбор быстрого, но небезопасного алгоритма - это то, чего, очевидно, ожидают от таких людей, как VMware и MS, а в «Unix» я бы предпочел предположить, что все будет «сделано правильно». Я не видел особых проблем с производительностью, пока у меня есть резервное хранилище снимков на разные диск, чем первичные данные (и резервное копирование на еще один, конечно)

Re: Барьеры Я не уверен, можно ли винить в этом LVM. Насколько я знаю, это была проблема с devmapper. Но может быть некоторая вина за то, что эта проблема не особо заботилась по крайней мере с ядра 2.6 до 2.6.33. AFAIK Xen - единственный гипервизор, который использует O_DIRECT для виртуальных машин, проблема была, когда использовался "цикл", потому что ядро все равно будет кешировать, используя это. Virtualbox, по крайней мере, имеет некоторые настройки для отключения подобных вещей, а Qemu / KVM, как правило, позволяет кешировать. У всех FUSE FS тоже есть проблемы (нет O_DIRECT)

Re: Размеры Думаю, LVM «округляет» отображаемый размер. Или он использует ГиБ. В любом случае вам нужно использовать размер VG Pe и умножить его на номер LE LV. Это должно дать правильный размер нетто, и эта проблема всегда связана с использованием. Это усугубляется файловыми системами, которые не замечают этого во время fsck / mount (hello, ext3) или не имеют работающего онлайн "fsck -n" (hello, ext3)

Конечно, это говорит о том, что вы не можете найти хороших источников такой информации. "сколько LE для VRA?" "каков физический сдвиг для PVRA, VGDA и т. д."

По сравнению с исходным LVM2 является ярким примером того, что «Те, кто не понимает UNIX, обречены на то, чтобы изобретать его заново».

Обновление через несколько месяцев: к настоящему моменту я использовал сценарий «полного снимка» для теста. Если они заполнятся, блокируется моментальный снимок, а не исходный LV. Я был неправ, когда впервые опубликовал это. Я взял неверную информацию из какого-то документа, или, может быть, я ее понял. В своих настройках я всегда был очень параноиком, чтобы не дать им заполниться, и поэтому я никогда не исправлялся. Также можно увеличивать / уменьшать снимки, что приятно.

Что я до сих пор не могу решить, так это как определить возраст снимка. Что касается их производительности, на странице проекта «thinp» Fedora есть примечание, в котором говорится, что методика создания снимков обновляется, чтобы они не замедлялись с каждым снимком. Я не знаю, как они это реализуют.

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

Кстати, если вы собираетесь использовать диск емкостью 1 ТБ, помните о выравнивании разделов - у этого диска, скорее всего, есть физические сектора 4 КБ.

Адам,

Еще одно преимущество: вы можете добавить новый физический том (PV), переместить все данные в этот PV, а затем удалить старый PV без каких-либо перерывов в обслуживании. За последние пять лет я использовал эту возможность как минимум четыре раза.

Недостаток, который я еще не заметил четко: для LVM2 довольно крутая кривая обучения. В основном в абстракции, которую он создает между вашими файлами и основным носителем. Если вы работаете с несколькими людьми, которые разделяют обязанности на одном наборе серверов, вы можете обнаружить, что дополнительная сложность подавляла бы вашу команду в целом. У более крупных команд, занимающихся ИТ-работой, такой проблемы не будет.

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

Следует особо отметить одно предостережение: если вы загружаетесь с логического тома LVM2, операции восстановления затрудняются при сбое сервера. У Knoppix и друзей не всегда есть для этого подходящие материалы. Итак, мы решили, что наш каталог / boot будет находиться в отдельном разделе и всегда будет маленьким и родным.

В целом я фанат LVM2.

Предлагая интересный обзор состояния LVM 10+ лет назад, принятый ответ теперь полностью устарел. Современные (например, LVM после 2012 г.):

  • соблюдает запросы синхронизации / барьера
  • имеет возможность быстрого и надежного создания снимков в виде lvmthin
  • иметь стабильное кеширование SSD через lvmcache и политика быстрой обратной записи для NVMe / NVDIMM / Optane через dm-writecache
  • оптимизатор виртуальных данных (vdo) поддержка благодаря lvmvdo
  • интегрированный и объемный RAID благодаря lvmraid
  • автоматическое выравнивание до 1 МБ или 4 МБ (в зависимости от версии), полностью избегая каких-либо проблем с выравниванием 4K (если не используется LVM для смещенного раздела)
  • отличная поддержка для увеличения объема, особенно при добавлении других блочных устройств (что просто невозможно при использовании классической файловой системы как ext4 / xfs поверх обычного раздела)
  • отличный, дружелюбный и чрезвычайно полезный список рассылки на linux-lvm@redhat.com

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

Пара вещей:

Распределение LV по нескольким PV

Я видел людей, выступающих за расширение (StackExchange и другие) ВМ пространство сбоку: увеличение пространства за счет добавления ДОПОЛНИТЕЛЬНО PV в VG по сравнению с увеличением НЕ ЗАМУЖЕМ PV. Это уродливо и распространяет вашу файловую систему (ы) на несколько PV, создавая зависимость от все более длинной и длинной цепочки PV. Вот как будут выглядеть ваши файловые системы, если вы горизонтально масштабируете хранилище виртуальной машины:

Потеря данных, если PV потерял хостинг Часть связанного LV

Я видел много путаницы по этому поводу. Если линейный LV- и файловая система, которая в ней живет- охватывают несколько PV, будет ли потеряна ПОЛНАЯ или ЧАСТИЧНАЯ? Вот проиллюстрированный ответ:

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

Надеюсь, эти маленькие каракули облегчили понимание сложных вопросов при работе с LVM.