Что такое lvmetad и почему я хочу или должен его использовать?

У меня есть сервер Gentoo с LVM, работающим поверх RAID-массива, который я использую в течение нескольких лет. Недавно я обновил LVM до 2.02.109 (не помню, какая это была версия) и получил сообщение при обновлении:

* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.

Я понимаю, что могу включить его, установив use_lvmetad = 1в /etc/lvm/lvm.conf.

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

Описание

Со страницы руководства lvmetad :

lvmetad - демон кэширования метаданных для LVM. Демон получает уведомления от правил udev (которые должны быть установлены, чтобы LVM работал правильно, когда используется lvmetad). Благодаря этим уведомлениям lvmetad получает актуальное и согласованное изображение групп томов, доступных в системе. По умолчанию lvmetad, даже если он запущен, не используется LVM. Смотрите lvm.conf (5).

Глядя на это немного ближе, заслуживает другого определения. Википедия утверждает:

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

аргументация

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

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

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

По этой ссылке :

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

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