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

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

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

Резюме

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

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

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

- Обновлен декабрь 2018: обновлен материал моментальных снимков, включая стабильность ZFS и btrfs в качестве альтернативы снимкам LVM

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

LVM все еще может хорошо работать, если вы:

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

подробности

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

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

• Кэширование записи и переупорядочение записи на жестком диске важно для хорошей производительности, но может не привести к правильной записи блоков на диск из-за гипервизоров виртуальных машин, кэширования записи на жесткий диск, старых ядер Linux и т. Д.
  • Барьеры записи означают, что ядро ​​гарантирует, что оно завершит определенные операции записи на диск перед «барьерной» записью на диск, чтобы обеспечить возможность восстановления файловых систем и RAID в случае внезапной потери питания или сбоя. Такие барьеры могут использовать операцию FUA (Force Unit Access) для немедленной записи определенных блоков на диск, что более эффективно, чем полная очистка кэша. Барьеры могут быть объединены с эффективной маркированной / встроенной очередью команд (выпуская несколько запросов ввода-вывода диска), чтобы позволить жесткому диску выполнять интеллектуальное переупорядочение записи без увеличения риска потери данных.
• У гипервизоров ВМ могут быть похожие проблемы: запуск LVM в гостевой системе Linux поверх гипервизора ВМ, такого как VMware, Xen , KVM, Hyper-V или VirtualBox, может создавать аналогичные проблемы в ядре без барьеров записи из-за кэширования записи и записи. -ordering. Внимательно изучите документацию своего гипервизора на предмет «записи на диск» или сквозного кэша (присутствует в KVM , VMware , Xen , VirtualBox и других) - и протестируйте его с настройками. Некоторые гипервизоры, такие как VirtualBox, имеют настройку по умолчанию, которая игнорирует любые очистки диска от гостя.
• Корпоративные серверы с LVM всегда должны использовать RAID-контроллер с батарейным питанием и отключать кэширование записи на жесткий диск (контроллер имеет кэш-память с резервным питанием от батареи, которая является быстрой и безопасной) - см. Этот комментарий автора этой записи XFS FAQ . Также может быть безопасно отключить барьеры записи в ядре, но рекомендуется тестирование.
• Если у вас нет RAID-контроллера с батарейным питанием, отключение кэширования записи на жесткий диск значительно замедлит запись, но сделает LVM безопасным. Вы также должны использовать эквивалент data=orderedопции ext3 (или 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 КБ, см. Ниже - при отключении кэширования записи могут возникнуть другие проблемы.
• ИБП имеет решающее значение как для предприятия, так и для 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 и данных журнала, которые, как думает ядро, уже находятся на диске, обычно приводят к значительному повреждению 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как указано выше.

• К сожалению, некоторые жесткие диски и твердотельные накопители лгут о том, действительно ли они сбросили свой кэш на диск (особенно старые диски, но в том числе некоторые диски SATA и некоторые корпоративные твердотельные накопители ) - подробнее здесь . Есть отличное резюме от разработчика XFS .
• Есть простой инструмент тестирования для лежащих дисков (скрипт Perl), или посмотрите этот фон с другим инструментом тестирования для переупорядочения записи в результате кеша дисков. Этот ответ охватывал аналогичное тестирование дисков SATA, которое выявило проблему барьера записи в программном RAID - эти тесты фактически используют весь стек хранения.
• Более поздние диски SATA, поддерживающие Native Command Queuing (NCQ), могут с меньшей вероятностью лежать - или, возможно, они работают хорошо без кэширования записи из-за NCQ, и очень немногие диски не могут отключить кэширование записи.
• Диски SCSI / SAS, как правило, в порядке, так как им не требуется кэширование записи для нормальной работы (через SCSI Tagged Command Queuing , аналогично SATA NCQ).
• Если ваши жесткие диски или твердотельные накопители лгут о сбрасывании их кэша на диск, вы действительно не можете полагаться на барьеры записи и должны отключить кэширование записи. Это проблема для всех файловых систем, баз данных, менеджеров томов и программного RAID , а не только для LVM.

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

• Большинство корпоративных твердотельных накопителей должны быть в порядке при управлении кэшем записи, а некоторые включают суперконденсаторы.
• Некоторые более дешевые SSD имеют проблемы, которые не могут быть исправлены с помощью конфигурации кэша записи - список рассылки проекта PostgreSQL и вики-страница Reliable Writes являются хорошими источниками информации. У потребительских твердотельных накопителей могут быть серьезные проблемы с кэшированием при записи, которые могут привести к потере данных, и они не включают суперконденсаторы, поэтому подвержены сбоям электропитания, вызывающим повреждение.

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

• В более новых дисках Advanced Format, которые используют физические секторы по 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 может обнаружить, что потерянный физический раздел содержит PV LVM, но ни один из этих инструментов не понимает логические тома LVM. Инструменты для вырезания файлов, такие как PhotoRec и многие другие, будут работать, обходя файловую систему, для повторной сборки файлов из блоков данных, но это последний вариант низкоуровневого подхода для ценных данных, который хуже работает с фрагментированными файлами.
• Ручное восстановление LVM возможно в некоторых случаях, но является сложным и отнимает много времени - см. Этот пример и это , это , и это для того, как восстановить.

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

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

• Кажется, что размер LV должен быть больше, чем размер FS, в 2 раза больше размера физического экстерьера (PE) LVM - но проверьте ссылку выше для деталей, так как источник этого не является достоверным. Часто достаточно 8 МБ, но может быть лучше позволить больше, например, 100 МБ или 1 ГБ, просто для безопасности. Чтобы проверить размер PE и ваш логический том + размеры FS, используя блоки 4 КиБ = 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 и измените размеры требуемых FS , тогда он сделает все за вас. На серверах вы можете использовать partedиз оболочки.

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

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

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

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

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

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

Снимки виртуальной машины / облака:

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

Ну, просто это разделение было по какой-то причине - различия проявляются в обработке потерь PV и онлайн-активации VG с отсутствующими PV, чтобы вернуть их в игру - Что является легким для «оригинальных LVM» (AIX , HP-UX) превращается в дерьмо на LVM2, так как обработка состояния недостаточно хороша. И даже не говорите мне об обнаружении потери кворума (хаха) или обработке состояния (если я удалю диск, он не будет помечен как недоступный. У него даже нет столбца состояния чертовски)

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

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

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

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

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

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

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

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

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

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

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

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

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

Адам,

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

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

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

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

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