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

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

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

  • LVM - Восстановление от повреждения таблицы разделов
  • Как добавить существующий обычный раздел в LVM в Linux?
  • Восстановление логических томов LVM после восстановления физических томов
  • Почему lvextend выделяет меньше указанного пространства?
  • LVM зависает при попытке создать мой узел корневого устройства
  • Изменение размера LVM в начале
  • Я предполагаю, что это проблема, когда некоторые внутренние таблицы не синхронизированы. Как получить правильное отображение вещей (без перезагрузки, который, я полагаю, исправит его)?


    Обновить:

    Ошибка перезагрузки НЕ исправила проблему. Я считаю, что проблема связана с конфигурацией «отсутствующего» 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 просматривает устройства?

  • два физических диска с одинаковыми именами групп томов, препятствующие доступу
  • Как разбить раздел crypt_LUKS пополам с LVM?
  • Почему существует несоответствие между размером, указанным LVM, и размером, указанным df -h?
  • Любая причина для шифрования /?
  • Почему некоторые из моих разделов lvm имеют «-real», добавленные к их именам?
  • Настройка кеша LVM для очень больших файлов
  • 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 

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

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

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