Команда «pvs» говорит, что устройство PV не найдено, но LV отображаются и монтируются

У меня была проблема с моей системой (неисправный внутренний кабель питания). Когда я получил резервную копию системы и перезапустил ее, восстановление массивов и т. Д., Похоже, ситуация, когда отчеты pvsvgs и lvs ) No device found for PV <UUID> но логический том, который находится на якобы отсутствующем физический том может быть успешно смонтирован, поскольку их DM-устройства существуют и отображаются в /dev/mapper .

PV-устройство представляет собой массив RAID-массива md-raid, который кажется прекрасным, за исключением путаницы, что он не появляется в выводе pvs .

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


Обновить:

Ошибка перезагрузки НЕ исправила проблему. Я считаю, что проблема связана с конфигурацией «отсутствующего» PV (/ dev / md99) в качестве массива RAID2 far-2, построенного на диске 750b (/ dev / sdk) и массиве RAID0 (/ dev / md90) с диска 250 ГБ (/ dev / sdh) и 500 ГБ диска (/ dev / sdl). Из вывода pvscan -vvv что подпись lvm2 находится на / dev / sdh, но не на / dev / md99.

  Asking lvmetad for VG f1bpcw-oavs-1SlJ-0Gxf-4YZI-AiMD-WGAErL (name unknown) Setting response to OK Setting response to OK Setting name to b Setting metadata/format to lvm2 Metadata cache has no info for vgname: "b" Setting id to AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN Setting format to lvm2 Setting device to 2160 Setting dev_size to 1464383488 Setting label_sector to 1 Opened /dev/sdh RO O_DIRECT /dev/sdh: size is 488397168 sectors /dev/sdh: block size is 4096 bytes /dev/sdh: physical block size is 512 bytes Closed /dev/sdh /dev/sdh: size is 488397168 sectors Opened /dev/sdh RO O_DIRECT /dev/sdh: block size is 4096 bytes /dev/sdh: physical block size is 512 bytes Closed /dev/sdh /dev/sdh: Skipping md component device No device found for PV AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN. Allocated VG b at 0x7fdeb00419f0. Couldn't find device with uuid AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN. Freeing VG b at 0x7fdeb00419f0. 

Единственной ссылкой на / dev / md99, которая должна быть PV, является то, когда она добавляется в кэш устройства.


Обновление 2:

Остановка lvm2-lvmetad и повторение pvscan подтверждают, что проблема заключается в том, что система путается о том, какие PV использовать, поскольку она находит 2 с тем же UUID

  Using /dev/sdh Opened /dev/sdh RO O_DIRECT /dev/sdh: block size is 4096 bytes /dev/sdh: physical block size is 512 bytes /dev/sdh: lvm2 label detected at sector 1 Found duplicate PV AzKyTe5Ut4dxgqtxEc7V9vBkm5mOeMBN: using /dev/sdh not /dev/md99 /dev/sdh: PV header extension version 1 found Incorrect metadata area header checksum on /dev/sdh at offset 4096 Closed /dev/sdh Opened /dev/sdh RO O_DIRECT /dev/sdh: block size is 4096 bytes /dev/sdh: physical block size is 512 bytes Incorrect metadata area header checksum on /dev/sdh at offset 4096 Closed /dev/sdh Opened /dev/sdh RO O_DIRECT /dev/sdh: block size is 4096 bytes /dev/sdh: physical block size is 512 bytes Closed /dev/sdh Incorrect metadata area header checksum on /dev/sdh at offset 4096 Telling lvmetad to store PV /dev/sdh (AzKyTe-5Ut4-dxgq-txEc-7V9v-Bkm5-mOeMBN) Setting response to OK 

поскольку эта конфигурация предназначена только для временного использования, я думаю, что мне лучше изменить порядок использования диска.

Разве никто не может сказать мне, как явно переопределить порядок, в котором pvscan просматривает устройства?

  • Системный раздел EFI поверх MD RAID и LVM
  • md raid1 ext3 и 4k сектора медленно работают с каталогами
  • RAIDing с LVM против MDRAID - плюсы и минусы?
  • Очень низкая производительность чтения по сравнению с производительностью записи на md (raid1) / crypt (luks) / lvm
  • md raid5: перевести номера внутреннего сектора md в смещения
  • Могу ли я восстановить имена файлов из отказавшего RAID0 (Linux Debian 5.0.8)
  • Найти соответствующие MD5 и XML в каталоге
  • Как Linux md-RAID обрабатывает ошибки чтения диска?
  • 2 Solutions collect form web for “Команда «pvs» говорит, что устройство PV не найдено, но LV отображаются и монтируются”

    Первое, что нужно проверить, это параметры filter и global_filter в /etc/lvm/lvm.conf . Убедитесь, что вы не отфильтровываете устройства, на которых находятся ваши PV.

    Кэш устанавливается с параметром cache_dir в том же файле; в моем поле Debian по умолчанию используется /run/lvm . Кэш (если есть) должен находиться в этом каталоге. Если установлено значение obtain_device_list_from_udev , я считаю, что кеш не используется.

    Наконец, проверьте, установлен ли параметр use_lvmetad . Если это так, вам может потребоваться перезапустить демон метаданных LVM.

    Проблема заключается в том, что pvscan запутывается, видя тот же UUID как на компонентном устройстве RAID-массива, так и на массиве RAID. Я предполагаю, что этого обычно избегают, признавая, что устройство является прямым компонентом. В моем случае я создал ситуацию, когда устройство не было непосредственно компонентом устройства RAID, которое должно быть PV.

    Мое решение состояло в том, чтобы создать резервную копию LVs, заставить массив деградировать, а затем перенастроить диски, чтобы не использовать многоуровневый RAID. Обратите внимание, что после другой перезагрузки надпись устройства изменилась. 500Gb = / dev / sdi, 250Gb = / dev / sdj, 750Gb = / dev / sdk

     # mdadm /dev/md99 --fail --force /dev/md90 # mdadm /dev/md99 --remove failed # mdadm --stop /dev/md90 # wipefs -a /dev/sdi /dev/sdj # wipe components # systemctl stop lvm2-lvmetad # pvscan -vvv # pvs ..... /dev/md99 is now correctly reported as the PV for VG b # fdisk /dev/sdi ...... Create 2 partitions of equal size, ie 250Gb # fdisk /dev/sdj ...... Create a single 250Gb patitiion # mdadm /dev/md91 --create -lraid5 -n3 /dev/sdi1 /dev/sdj1 missing # mdadm /dev/md92 --create -lraid1 -n2 /dev/sdi2 missing # pvcreate /dev/md91 /dev/md92 # vgextend b /dev/md91 /dev/md92 # pvmove /dev/md99 # vgreduce b /dev/md99 # pvremove /dev/md99 # mdadm --stop /dev/md99 # wipefs -a /dev/sdk # fdisk /dev/sdk ..... Create 3 250Gb partitions # mdadm /dev/md91 --add /dev/sdk1 # mdadm /dev/md92 --add /dev/sdk2 

    Мораль истории:

    Не вводите слишком много уровней косвенности в файловую систему!

    Interesting Posts

    Найти, какие файлы в папке не известны менеджеру пакетов apt

    Начальное правило iptable и операция knockd в vps

    замените строку строки 6 после сопоставления строки

    lemonbar в openbox всегда используется в других приложениях

    Wget не конвертирует ссылки и загружается правильно?

    Почему не совместим с GNU / Linux SUS v3 +?

    Почему некоторые приложения оставляют события KeyRelease потребляемыми следующим ориентированным приложением / окном

    Как настроить систему отказоустойчивости в CentOS 6.0

    Перенаправить stderr в конструкцию с двойными скобками

    Не удалось запустить поиск elastics

    Помимо USR1 и USR2, какие сигналы можно безопасно использовать для пользовательского прерывания поведения? (в python)

    Как использовать правила udev для управления / dev / xxx при работе в контейнере

    200 мс между TCP send и tcpdump только с большими сообщениями

    luakit + awesome wm: сделать полноэкранную работу youtube

    Как найти устройство, к которому подключен USB-узел в операционной системе Linux?

    Linux и Unix - лучшая ОС в мире.