Поэтому я задаю этот вопрос исключительно для того, чтобы опубликовать собственное решение. Я столкнулся с ситуацией, когда мои диски выглядели так:
LVM
DRBD-RESOURCE
UNDERLYING-BLOCK-DEVICE
Используя Drbd 9, я столкнулся с проблемой, когда LVM находил подписи lvm на нижележащем блочном устройстве, и у меня был действительно плохой день. В lvm conf фильтры категорически не работали. Я попробовал фильтры из документации, а также свои собственные и любые сообщения на форуме, которые смог найти. Я даже ограничил тип устройства drbd, и от этого ничего не заработало. Даже если я запустил pvscan, vgscan, lvmconfig. Неважно, не сработало.
Фильтры должны работать так, как указано в документации, найденной здесь: https://www.drbd.org/en/doc/users-guide-84/s-lvm-drbd-as-pv
Для полноты изложения эти шаги заключаются в добавлении фильтра, отключении записи кеша метаданных LVM и стирании любого созданного кеша.
В /etc/lvm.conf:
...
filter = [ "a|drbd.*|", "r|.*|" ]
...
write_cache_state = 0
...
Затем также удалите любой кеш:
# rm /etc/lvm/cache/.cache
В CentOS 7 в дополнение к шагам, описанным выше, вам нужно либо остановить и отключить lvm2-lvmetad.service, либо установить use_lvmetad = 0 также в lvm.conf. Последнее требует перезагрузки.
Мое решение заключалось в использовании ресурса в директиве сканирования в lvm.conf в разделе «устройства»:
/ dev / drbd / by-res / [НАЗВАНИЕ ВАШЕГО РЕСУРСА]
Очевидно, что вы не могли использовать lvm ни с чем другим, но это было нормально для меня и единственное, что работало.
@Matt Kereczman указал:
В CentOS 7 в дополнение к шагам, описанным выше, вам нужно либо остановить и отключить lvm2-lvmetad.service, либо установить use_lvmetad = 0 в lvm.conf. Последнее требует перезагрузки.
Похоже, это решило одну последнюю проблему, с которой я столкнулся. Вы можете найти его ответ полезным, я придерживаюсь своего пути сканирования, потому что он работает для меня.