Кажется, я плохо объяснил:
- drbd собран поверх  lvm-диска и занимает весь его объем;
- увеличиваю размер lvm-диска;
- теперь нужно как-то сообщить drbd о том, что размер поменялся. Данные, которые поверх drbd должны остаться целыми.

Вот не надо сейчас на drbd громоздить lvm-тома. А именно - имел на прошедший Новый Год (в аккурат на праздники) большую проблему с этим. Даже не проблему, а фатальный крах на связке CentOS-6.5+drbd+LVM. Долгое время всё работало без проблем. А вот здесь решил обновить систему. Обновилось, как водится и ядро оси. Ну а после этого рухнули (от слова абсолютно) LVM-разделы, что жили на одном большом drbd-томе. Ситуация была устойчивой и уверенно воспроизводилась как на реальном, рабочем, железе, так и на виртуальных машинах.
Так что теперь вместо одного drbd-тома и нескольких LVM-томов на нем пользую несколько мелких LVM-томов, которые связываю по drbd. Соответсвенно, не знаю исправилась на более новых ядрах ситуация или нет. Не знаю.

Но бэкапы - рулят. Без них была бы форменная катастрофа.

Спасибо за комментарии - задумался.

Мне эта идея тоже не понравилась, но это делалось для proxmox: он создает логические тома в группе при создании диска VM.
А какая была версия drbd?

"я же говорил: место проклятое, а ты: "руки кривые, руки кривые" (с) анек
То-то он у меня на тестовой связке пару раз легко слетел.

После того как выяснилось, что fencing у меня будет в лучшем случае вручную, то наверное сделаю primary/secondary, т.к. в любом случае ручками лазить придется.

Для двух хиленьких недо-серверов, соединеных 1Gb сетью:
- ceph: не подходит по ТТХ (3 сервера, не очень слабые);
- gluster: быстрый гуглеж показал наличие отзывов о нестабильности и показалось, что мое железо тоже не сильно подходит;
- zfs: а разве это "сетевая" фс?!

Я правильно понял:
- "а/а" == primary/primary ?
- "не трогать" == не использовать ?

Версия - 8.4.4. Последняя на декабрь прошлого года. Какая сейчас последняя - не скажу, не знаю. Работало всё в режиме Primary/Secondary и никак иначе. Компилировалась она на нужное ядро самостоятельно, на виртуальной машине стенда. Причем, что самое печальное - LVM на DRBD жил у меня несколько лет вполне утойчиво и беспроблемно. Менялось при обновлениях ядро - автоматом (после загрузки с новым ядром) перекомпилировался соответствующий модуль drbd и всё работало как часы. Я просто не ожидал такой полянки, делал большое новогоднее обновление из дома... А оно - возьми и обломайся полностью. Хорошо была неделя в запасе на починку установки.

По гластеру - мне он тоже нравится. И я его тоже использую, храню на нём архивы и конфигурационные файлы и различные скрипты, которые должны быть синхронизированы на нескольких серверах.  Очень удобно. Но у него есть один недостаток - он плохо ложится под самбу. Не держит он блокировок самбовых. В результате у меня 1С (7.7 файловый) на нём валился на раз при совместном доступе. И еще тот же ворд от мелкомягких не мог открывать сетевые файлы. Вис намертво. Перенёс всю самбу на drbd - всё работает четко, как в аптеке.

Такой вот личный опыт. Скоро опять Новогодние каникулы... Может еще что нового для себя открою...

Это понятно. Я их и не сравниваю. Я как раз об особенностях применения пишу.  Особенностях, которые вылезают при работе третьих (если не четвертых) приложений.
Хотя - до сих пор понять не могу - что же там в LVM изменилось, что оно на DRBD жить не захотело...

Спасибо за содержательный ответ!
[offtop]
Узнал даже то, чего не спрашивал. А если бы чуть активнее искал в гугле, то нашел бы ответ _только_ на свой вопрос и вероятнее всего встал бы на те же грабли.
[/offtop]

Можно же написать, или проверить пригодность уже имеющихся от старого пакета. Не копал, но думаю, что в тарболе с исходниками должны быть или заготовки, или уже готовые правила, которые достаточно при создании пакета скопировать в $PKG/lib/udev/rules.d.