Назад | Перейти на главную страницу

Удалить повторяющийся uuid физического тома lvm?

Сегодня, после обновления сервера rhel 5, я перезагрузился на новое ядро: curr = 2.6.18-371.el5PAE prev = 2.6.18-348.18.1.el5PAE.

В последовательности загрузки я увидел сообщение о запуске Logical Volume Management, а затем почти сразу же увидел это, и мне предложили оболочку для восстановления:

Обнаружен дубликат PV BPF ... ayV: используется / dev / sdc1, а не / dev / md3.

Примечание. / Dev / sdc1 и / dev / sdb1 являются членами массива raid1 / dev / md3.

Исходя из этого, я предположил, что программное обеспечение lvm2 считает, что / dev / sdc1 и / dev / md3 являются pv с одинаковым UUID и что программное обеспечение lvm2 игнорирует / dev / md3 и использует / dev / sdc1.

Я выключил питание, отключил диск для SDC и перезапустил. Неожиданно система загрузилась, и я не заметил никаких проблем. Конечно, md3 деградировал.

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

Файловая система на проблемном логическом томе была смонтирована.

Я выполнил pvdisplay и увидел ту же ошибку выше. Конечно, когда я попытался добавить sdc1 обратно в md3, это не позволило мне, потому что он использовался программным обеспечением lvm2.

Я размонтировал файловую систему и запустил e2fsck на пути устройства lv. Никаких проблем там (но проблемы должны были быть).

На самом деле есть четыре связанных вопроса (извините). Если предположить, что ответ 3 - «да» или «вроде как», то ответ на 4 - это то, что мне нужно. Я спросил первых двух, потому что предполагаю, что мне нужно понять их ответы, чтобы разобраться в любом ответе на последние два.

  1. Почему файловая система в порядке, если логический том изначально был составлен из pv / dev / md3 вместо / dev / sdc1?

  2. Разве / dev / sdc1 не должен отличаться от / dev / md3, чтобы предотвратить согласованность логического тома с физическими томами внутри? На это можно ответить, задав вопрос 1.

  3. Могу ли я решить свою проблему, удалив информацию о pv из / dev / sdc1 и добавив / dev / sdc1 обратно в / dev / md3?

  4. Если ответ на вопрос №3 - да, то как мне это сделать, не разрушая логический том и его файловую систему?

Немного истории:

Я никогда не выполнял "pvcreate / dev / sdc1", поэтому понятия не имею, почему это должно происходить. Однако это правда, что / dev / sdc в последнее время беспокоит меня тем, что smartmon (sp?) Скажет мне, что он не может читать интеллектуальные данные или даже не видит устройство. Я исправлю проблему либо (а) перезагрузкой, (б) перезагрузкой + зависанием BIOS + выключением питания + сбросом кабеля sata + включением питания, либо последовательностью б, но заменой кабеля sata вместо того, чтобы просто переустановить его.

  1. Я не уверен, что вы задали вопрос, который, как вы думаете, задали, но / dev / md3 - это то же самое, что / dev / sdb1 и / dev / sdc1, поскольку это зеркальный набор.

  2. Нет, не должно.

  3. Нет, это приведет к потере данных.

  4. Нет данных

Вероятно, вы можете избавиться от этого сообщения об ошибке, изменив свой /etc/lvm.conf файл, чтобы изменить фильтр для отклонения устройств sdb * и scd *, повторно обновите свой initrd, затем перезагрузитесь.

Основная проблема заключается в том, что массив был создан с суперблоком MD в конце, что означает, что суперблоки в начале все еще узнаваемы на их ожидаемых смещениях. Единственное, что препятствует синтаксическому анализу суперблока PV, - это то, что подсистема MD сначала захватывает устройства; обычно. Иногда верхние слои проявляют осторожность, когда обнаруживается еще один суперблок, но он может быть хрупким.

Есть два способа избежать этого.

  • Создайте массив с --metadata = 1.2, который используется по умолчанию с 2010 года. Суперблок PV будет сдвинут на 512 КБ и не будет распознаваться на несобранных устройствах.
  • Используйте интеграцию LVM с MD. Уточнить --type=raidXX к lvcreate или lvconvert. LVM не выставляет разобранные устройства.

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

Убедившись, что массив синхронизирован и файловая система в основном работает нормально, вы можете разобрать его, уничтожить суперблоки рейда на обоих дисках (прочтите wipefs manpage, вы не хотите по ошибке уничтожить суперблоки PV), уничтожьте суперблок PV только на одном члене, расширите свой VG на него и lvконвертируйте свои логические тома в --type=raid1 --mirrors=1. Наконец, повторно запустите grub-install на обоих дисках.