Вопрос: LVM опасности и оговорки


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

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


174
2018-06-12 07:34


Источник


Читая ответы на этот вопрос, помните дату (год), которую они опубликовали. За 3 года в этой отрасли много всего происходит. - MattBianco
Недавно я обновил некоторые обновления (апрель 2015 г.), чтобы проверить, не изменилось ли что-либо. Ядро 2.6 теперь устарело, SSD более распространены, но, кроме некоторых небольших исправлений LVM, многое изменилось. Я написал некоторые новые вещи при использовании моментальных снимков VM / облачного сервера вместо снимков LVM. Насколько я вижу, состояние кэширования записи, изменение размеров файловой системы и моментальных снимков LVM существенно не изменилось. - RichVel
в отношении комментариев «не забывайте о дате» - правда, но также считаем, что многие «предприятия» по-прежнему используют RHEL 5 и RHEL 6, оба из которых являются самыми современными или старше даты ответа - JDS


Ответы:


Резюме

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

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

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

- Обновлен сентябрь 2017 года: сделал старый материал ядра менее заметным

Смягчение рисков

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

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

Детали

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

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

  • Запись кэширования и запись переупорядочения на жестком диске важна для хорошей производительности, но может не правильно очистить блоки на диске из-за гипервизоров VM, кэширования на жестком диске, старых ядер Linux и т. д.
    • Писать барьеры означает, что ядро ​​гарантирует, что оно завершит определенные записи на диске до записи «барьерного» диска, чтобы гарантировать восстановление файловых систем и RAID в случае внезапной потери питания или сбоя. Такие барьеры могут использовать Операция FUA для немедленной записи определенных блоков на диск, что более эффективно, чем полный кеш-флеш. Барьеры могут сочетаться с эффективными помеченный/родной (одновременное выдача нескольких запросов ввода-вывода на диск), чтобы позволить жесткому диску выполнять интеллектуальный переупорядочивание записи без увеличения риска потери данных.
  • Гипервизоры VM могут иметь схожие проблемы: запуск LVM в гостевом приложении Linux поверх гипервизора VM, такого как VMware, Xen, KVM, Hyper-V или VirtualBox могут создавать аналогичные проблемы к ядру без барьеров записи, из-за кэширования записи и переупорядочения записи. Внимательно проверьте свою гипервизорную документацию на наличие «флеш-диска» или опции кэширования записи (присутствует в KVM, VMware, Xen, VirtualBox и другие) - и протестируйте его с помощью вашей настройки. Некоторые гипервизоры, такие как VirtualBox, имеют настройка по умолчанию который игнорирует любые дискеты от гостя.
  • Серверы предприятия с LVM должны всегда использовать RAID-контроллер с батареей и отключить кэширование записи на жесткий диск (у контроллера есть резервный кеш памяти, который работает быстро и безопасно) - см. этот комментарий автор этот вопрос в FAQ XFS, Он также может быть безопасным для отключить барьеры записи в ядре, но рекомендуется тестирование.
  • Если у вас нет контроллера 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 с множеством патчей. Если эти старые ядра ядра не загружены для этих проблем, большое количество метаданных FS (включая журналы) может быть потеряно из-за жесткого сбоя, который оставляет данные в буферах записи на жестких дисках (скажем, 32 МБ на диск для обычных дисков SATA). Потеря 32 МБ из недавно написанных FS-метаданных и журнальных данных, которые, по мнению ядра, уже находятся на диске, обычно означает много коррупции FS и, следовательно, потерю данных.
  • Резюме: вы должны позаботиться о файловой системе, RAID-массиве, гипервизоре VM и настройке жесткого диска / SSD, используемой с LVM. У вас должны быть очень хорошие резервные копии, если вы используете LVM, и обязательно создавайте резервные копии метаданных LVM, физических разделов, MBR и загрузочных секторов. Также рекомендуется использовать диски SCSI / SAS, поскольку они менее склонны лгать о том, как они выполняют кэширование записи - для использования дисков SATA требуется больше внимания.

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

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

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

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

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

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

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

  • Любое восстановление данных 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, и вы можете в основном пропустить этот раздел.
  • Большинство руководств по изменению размера FSS на основе LVM не учитывают тот факт, что FS должен быть несколько меньше размера LV: подробное объяснение здесь, При сжатии файловой системы вам нужно будет указать новый размер для инструмента изменения размера FS, например. resize2fs для ext3 и для lvextend или lvreduce, Без особой осторожности размеры могут несколько отличаться из-за разницы между 1 ГБ (10 ^ 9) и 1 Гигабайт (2 ^ 30), или как различные инструменты вокруг размеров вверх или вниз.
  • Если вы не выполняете вычисления точно (или используйте некоторые дополнительные шаги за пределами наиболее очевидных), вы можете оказаться в FS, который слишком велик для LV. Все будет выглядеть отлично в течение нескольких месяцев или лет, пока вы полностью не заполните FS, и в этот момент вы получите серьезную коррупцию. И если вы не знаете об этой проблеме, трудно понять, почему, поскольку к тому времени вы также можете иметь реальные ошибки в диске которые окутывают ситуацию. (Возможно, эта проблема влияет только на уменьшение размера файловых систем - однако ясно, что изменение размеров файловых систем в любом направлении увеличивает риск потери данных, возможно, из-за ошибки пользователя.)
  • Кажется, что размер LV должен быть больше размера FS на 2 x размер физической протяженности LVM (PE), но проверьте ссылку выше для деталей, поскольку источник для этого не является авторитетным. Часто допускается 8 MiB, но может быть лучше разрешить больше, например. 100 MiB или 1 GiB, чтобы быть в безопасности. Чтобы проверить размер PE и ваш логический объем + размеры FS, используйте 4 байта KiB = 4096 байт:

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

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

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

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

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

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

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

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

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

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

VM / облачные снимки:

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

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

  • моментальные снимки уровня файловой системы с ZFS или btrfs просты в использовании и, как правило, лучше, чем LVM, и хотя ни одна из файловых систем не очень зрелая в Linux, они могут быть лучшим вариантом для людей, которым действительно нужны снимки без перехода на виртуальный / облачный маршрут:

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

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

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

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

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

Выводы

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

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

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

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


237
2018-06-12 08:19



Онлайн-изменение размера с помощью xfs отлично работает, вам даже не нужно указывать размер. Он будет расти до размера LV, читаемого больше в xfs_grow (5). OTOH Я нажимаю +1 для сводки о барьерах записи. - cstamas
не должна быть ваша вторая пуля включить с резервным аккумулятором? Следующая пуля запрещать без батареи. Кроме того, как говорили другие, очень мало файловых систем требуют указания размера для операции изменения размера. Большинство считают это автоматически. - TREE
@TREE: идея с RAID-контроллером с батарейным питанием заключается в том, что его кеш постоянно сохраняется при сбоях питания и обычно может быть надежно работать как задокументированный, тогда как некоторые кэши жесткого диска ложатся на то, действительно ли они написали блок на диск, и Конечно, эти кеши не настойчивы. Если вы оставите кеш жесткого диска включен, вы уязвимы для внезапного сбоя питания (например, сбой блока питания или ИБП), который защищен резервным аккумулятором RAID-контроллера. - RichVel
Один из лучших ответов, которые я когда-либо видел, любую тему. Только изменение, которое я сделал бы, перевести резюме в ТОП вопроса для тех, кто с синдромом дефицита внимания или не так много времени. :-) - Prof. Falken
Увидев все комментарии и последнее обновление для ответа было год назад, мне было интересно, можно ли обновить ответ, чтобы отразить любые новые изменения в надежности, производительности и простоте использования. - Luis Alvarado


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

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

Пол: Мужской pvmove... почему

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

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

Re: Снимки CoW выполняется небезопасно, обновляя НОВЫЕ данные в области снимка lv и затем объединяясь, как только вы удаляете привязку. Это означает, что у вас большие всплески IO во время окончательного слияния новых данных в исходном 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 делает «округление» отображаемого размера. Или он использует GiB. Во всяком случае, вам нужно использовать размер VG Pe и умножить его на LE-номер LV. Это должно дать правильный размер сети, и эта проблема всегда является проблемой использования. Это усугубляется файловыми системами, которые не замечают такую ​​вещь во время fsck / mount (hello, ext3) или не работают в режиме онлайн «fsck -n» (hello, ext3)

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

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

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

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


15
2017-12-11 14:03



Хорошие моменты, особенно на потерю данных pvmove (не понимал, что это может произойти сбой при низкой памяти) и дизайн снимка. На барьерах записи / кэшировании: я сочетал LVM и устройство отображения ядра, поскольку с точки зрения пользователя они работают вместе, чтобы обеспечить то, что обеспечивает LVM. Upvoted. Также понравилась ваша запись в блоге о потере данных pvmove: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
На моментальных снимках: они, как известно, медленны в LVM, поэтому было явно нехорошим дизайнерским решением идти на повышение надёжности. «Ударив стену», вы имели в виду, что моментальный снимок заполняется, и может ли это привести к повреждению исходных данных LV? LVM HOWTO говорит, что снимок снижается в этом случае: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
«CoW выполняется небезопасно, обновляя НОВЫЕ данные в области снимка lv, а затем сливаясь обратно, как только вы удалите привязку». Это просто неверно. Когда новые данные записываются на исходное устройство, старый версия записывается в область COW снимков. Никакие данные никогда не сливаются обратно (за исключением случаев, когда вы хотите). Видеть kernel.org/doc/Documentation/device-mapper/snapshot.txt для всех технических деталей. - Damien Tournoud
Привет, Дэмиен, в следующий раз просто прочитал вопрос, где я исправил свой пост? - Florian Heigl


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

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


12
2018-06-12 09:44



+1 для предупреждения о производительности для открытых снимков. - Prof. Falken
мой опыт в том, что 1TB-диски обычно используют 512-байтовые сектора, но большинство приводов 2TB используют 4Kb. - Dan Pritts
@DanPritts не вредит, если предположить, что размер сектора составляет 4 КБ или даже 128 КБ - на всякий случай, если между ними происходит рейд. вы теряете так мало - может быть, 128 КБ, и вы можете получить много. также при визуализации с старого диска на новый. - pQd
Существует некоторый незначительный вред, когда размер блока файловой системы «слишком велик»; каждый файл содержит не менее одного блока. Если у вас много крошечных файлов и 128 КБ блоков, это будет складываться. Я согласен с тем, что 4K вполне разумно, и если вы переместите файловую систему на новое оборудование, вы в конечном итоге получите 4k сектора. - Dan Pritts
(не позволяю мне редактировать мой предыдущий комментарий) ... Пустота пространства может не иметь значения, но в конечном итоге это увеличит среднее время поиска на вращающихся дисках. Возможно, это может привести к усилению записи (заполнение сектора нулями) на SSD. - Dan Pritts


Адам,

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

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

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

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

В целом, я поклонник LVM2.


5
2018-06-22 21:03



хранение /boot отдельная всегда хорошая идея - Hubert Kario
GRUB2 поддерживает загрузку с логического тома LVM (см. wiki.archlinux.org/index.php/GRUB2#LVM), но GRUB1 этого не делает. Я бы всегда использовал отдельную не LVM / boot, чтобы обеспечить ее легко восстановить. Большинство спасательных дисков в наши дни поддерживают LVM - некоторые требуют руководства vgchange -ay для поиска томов LVM. - RichVel
на pvmove: см. пункт о потере данных pvmove, сделанный в ответе Флориана Хейгла. - RichVel