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

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

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

Источник

6 ответов

Решение

Резюме

Риски использования 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) для немедленной записи определенных блоков на диск, что более эффективно, чем полная очистка кэша. Барьеры могут быть объединены с эффективной маркированной / встроенной очередью команд (выпуская несколько запросов ввода-вывода диска), чтобы позволить жесткому диску выполнять интеллектуальное переупорядочение записи без увеличения риска потери данных.
  • У гипервизоров VM могут быть похожие проблемы: запуск LVM в гостевой системе Linux поверх гипервизора VM, такого как VMware, Xen, KVM, Hyper-V или VirtualBox, может создавать аналогичные проблемы для ядра без барьеров записи из-за кэширования записи и записи. -ordering. Внимательно проверяйте документацию гипервизора на наличие "кэш-памяти" или опции сквозного кэша (присутствует в 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 КБ, см. Ниже - при отключении кэширования записи могут возникнуть другие проблемы.
  • ИБП имеет решающее значение как для предприятия, так и для 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 как указано выше.

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

Расширенная настройка формата диска - запись, кэширование, выравнивание, 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 [исправлено в Debian initramfs-tools обновление, март 2015]).

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

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

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

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

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

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

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

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

Снимки можно использовать для обеспечения согласованного источника резервных копий, если вы осторожны с выделенным пространством (в идеале моментальный снимок имеет тот же размер, что и резервное копирование LV). Превосходный http://rsnapshot.org/ (начиная с 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.

Источник

Предлагая интересный обзор состояния 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.

Источник

Я [+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.

Источник

Пара вещей:

Объединение LV на несколько PV

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

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

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

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

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

Источник
Другие вопросы по тегам