Подозрение справедливое. Но... Никакого оффсета не слетает.

ну как бы испорченная метадата, или правильная метадата, указывающая на уехавший оффсет приводят к одному результату

DRBD

подозреваю что где то слетает оффсет в который прописана метадата

Подозрение справедливое. Но... Никакого оффсета не слетает. Специально сравнил конфигурации LVM-тома. Забэкапленные и нынешние. Один в один. Здесь нет различий. А вот поражения внутри тома в полный рост имеем. У меня на drbd-томе было развернуто 6 LVM-томов. Один под файловую помойку и 5 под виртуальные машины, доступ к которым делался по iSCSI. После краха ни один том не ожил. То есть - все полностью дохлые и ничего в системе не возбуждают. С помощью R-Studio вытащил из покойника кучу файлов. Но... Отдельные спасенные "файлы" имеют совсем произвольное содержимое. То есть файловая система (файлового сервера) там накрылась полным медным тазом. Конечно, я виноват в том, что не делал регулярно fsck на эту файловую систему, полагал, что при очередной перезагрузке компа и её монтировании  она проверится. Но вот только сервер перегружался не чаще чем раз в месяц. Возможно там разрушения самонакопились. Но вот почему рухнули и другие разделы, с виртуалками (причем все одновременно)- не знаю. Для меня - вероятность такого разрушения равна нулю. Но, тем не менее оно рухнуло. Причем все 6 томов одновременно. Ввод простой - что-то их крушило единовременно. Что-то в системе колом встало и тома обрушило. Но что именно крушило - догадок нет никаких.

DRBD знает, что именно с ним работает? То есть - понимает, что там LVM-тома или просто файловая система развернута?

нет, это просто блочное устройство.

подозреваю что где то слетает оффсет в который прописана метадата

Cruiser78 пишет:

Связка же сделана прямо по учебнику

она от этого не станет менее глючной. DRBD падает и ломается, это надо принять и с этим жить. Или перейти на другую систему, о чем я говорил с самого начала

Пара простых вопросов:
- DRBD знает, что именно с ним работает? То есть - понимает, что там LVM-тома или просто файловая система развернута?
- Если оно не понимает, а работает как блочное зеркало, то почему LVM на нем в 6.5 гарантированно валится, а в 6.4 - работает? При этом файловая нарезка работает и там и там?

И еще. У меня есть подтвержденное проверкой соображение, что DRBD весьма долго "спасал" положение. А именно - system-config-lvm ведет себя совершенно по разному в зависимости от того, есть drbd или его нет.
Описание опыта на CentOS 6.4:
1. DRBD запущен и работу ведем на его primary-ноде.
1.1 создаем физический том (pvcreate);
1.2. создаем группу томов (vgcreate);
1.3. Запускаем system-config-lvm и видим созданную группу томов.
2. удаляем эти настройки.
3. отключаем DRBD напрочь.
4.1 Создаем физический том LVM на LVM-разделе, на котором раньше жил DRBD;
4.2 Создаем там группу томов (lvcreate);
5.   Запускаем system-config-lvm  и он сваливается напрочь, не может просканировать LVM на машине.
6. Но... руками (lvcreate) мы тома создать можем, можем создать на них файловые системы и смонтировать в нужное место.
На CentOS6.5 поведение несколько иное. А именно - руками на LVM-томе всё создается. И точно так же как в 6.4 system-config-lvm валится напрочь. Но,если мы пытаемся разместить наши новые тома на drbd-томе, то до lvcreate мы дойти не можем. vgcreate не отрабатывает должным образом и, в отличие от 6.4 system-config-lvm не может запуститься уже после pvcreate.

Как-то так...

Вывод - ошибка появилась сильно ранее, но размещение DRBD

Связка же сделана прямо по учебнику

она от этого не станет менее глючной. DRBD падает и ломается, это надо принять и с этим жить. Или перейти на другую систему, о чем я говорил с самого начала

Cruiser78 пишет:

Так что имеем серьезную системную багу в CentOS 6.5

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

Мне квалификации не хватает понять, где именно собака зарылась. Связка же сделана прямо по учебнику. А именно:
Собственно CentOS, на нем - LVM, на котором  выделен отдельный раздел, который отдан под DRBD. Далее, на этом DRBD-томе поднята группа LVM-томов, которые предназначены уже для разных нужд, для файло-помойки или под образы виртуальных машин. Все очень удобно настраивается. И до последнего дня проблем при апдейтах не было. А вот переход с CentOS 6.4 на CentOS 6.5 эту стройную систему поставил раком. Причем, я уверен - раком стоит не drbd. Сейчас я его тривиально развернул (без последующей LVM-нарезки) и накатил на него данные с архива. И оно работает... А вот LVM на него уже не накатить. А вот что именно мешает - не знаю.

Так что имеем серьезную системную багу в CentOS 6.5

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

Cruiser78 пишет:

Вывод dmesg - что именно показывать?

Пока не знаю, навеяно этим https://bugzilla.redhat.com/show_bug.cgi?id=956387#c10

Там немного про другое. Там уже в полный рост lvcreate некорректно себя ведет. А у меня, как я выяснил путем проб и ошибок, до этой стадии не добраться. А именно, на CentOS 6.5 c 431-м ядром:
- Делай раз. То есть создаем DRBD-том. ОК.
- Делай два. Создаем физический LVM-том. То есть pvcreate /dev/drbd0. Проверяем pvscan'ом. OK.
- Делай три. Создаем группу LVM-томов. То есть vgcreate vg_drbd /dev/drbd0. Как учили. Вывод показан выше. Проверяем pvscan'ом. Oops...
И так можно бесконечно повторять второй и третий пункты. Я боюсь, что программы уровня vg* что-то корячат на томе. И как глубоко эта раскоряка проникает я не знаю. То есть, не уверен, что смогу реанимировать из дампа свой том и достать из него данные.
====================================
Собрал на виртуалках следующий стенд:
1. Ноды - одна на CentOS 6.4 (ядро 358), вторая - на СентОС 6.5 (со всеми последними обновлениями).
2. DRBD версии 8.4.4
Результат - если поднимать LVM-тома на ноде CentOS 6.4, то все работает как доктор прописал. Критерий истины - работа system-config-lvm. Работает,  тома показывает, нарезает...
Однако, если сделать primary-нодой узел на CentOS 6.5, то всё абсолютно повторяется, как я описывал выше. pvcreate физический том создает, а vgcreate его крушит, system-config-lvm не запускается и вываливается с кучей мне непонятных ошибок....

Так что имеем серьезную системную багу в CentOS 6.5

Вывод dmesg - что именно показывать?

Пока не знаю, навеяно этим https://bugzilla.redhat.com/show_bug.cgi?id=956387#c10

Можно конечно накатить vgcfgrestore
Но боюсь это только усугубит ситуацию.
Ты одновременно обе ноды обновил?

Ноды обновлялись одновремеено. vgcfgrestore накатывать пытался. Система её отвергла. Сейчас проинициализировал drbd и пытаюсь создать на нем снова группу томов LVM. Обломайтис....
Запускаю pvcreate /dev/drbd0. Проходит нормально, последующий запуск pvscan показывает, что оно создалось. Далее, по инструкции, vgcreate vg_drbd /dev/drbd0.... И вот тут - опаньки, сообщается, что:

А вот просто создать файловую систему на этом томе и подвигать её между хостами - это завсегда пожалуйста... Без проблем. 
Похоже, придется создать несколько LVM-томов на "базе" и на каждом в отдельности поднимать мелкие (под виртуальные машины) drbd-тома. Которые и раздавать через iSCSI серверам.

Похоже, что что-то разработчики LVM поломали в своем продукте. Гады...
Хотя... Кто знает, что именно поломато. С утра сделал простую операцию - распаковал прямо поверх установленных device-mapper и lvm2 из CentOS 6.4. Не помогло. Эффект был тот же.
Так что есть вариант снова поставить CentOS 6.4 на сервера и влить в него сохраненный образ drbd-тома. Вдруг оживет...

Может стоить по чистить  /etc/lvm/cache/.cache ?

Нечего там чистить. Пусто.
Вывод dmesg - что именно показывать?
Чем дальше я кувыркаюсь, тем более стойкое у меня ощущение, что СХД превратилось в кирпич...
Что было сделано - вместо одной ноды в drbd подключил новый комп. Данные по drbd на него залились за пару часов. Но и новый комп ничего видеть не захотел.
Как раньше было - поставил drbd-том в primary-режим, настроил на нём LVM-группы, переключился на резервную ноду. Там system-config-lvm прекрасно всё видит и подхватывает настройки. А здесь - полный облом, глухо как в танке.

Покажите еще fdisk -l и pvscan

То есть, сам большой drbd-том виден. И, скорее всего, LVM-информация с него какая-то читается. То есть  lvscan LVM-нарезку показывает. А вот дальше - облом. Не хочет воспринимать, как я понимаю, device-mapper какой-то параметр, что ему дает LVM, а именно - lvchange -ay... А вот что это за параметр и почему он не нравится device-mapper'у - для меня есть тайна.

И, самое интересное - отключил drbd (чтобы не попортить том) выполнил команду vgremove vg_drbd. Нарезка убралась, pvscan говорит, что том LV_DRBD без каких либо подтомов. Включаю снова drbd...pvscan содержимого тома не видит и состояние не обновляет. Переключаю primary на другую ноду, там pvscan показывает разделы на томе. Ощущение, что LVM работает вообще с каким-то кэшем, а к drbd-диску не обращается.