O comando 'pvs' diz que o dispositivo PV não foi encontrado, mas os LVs são mapeados e montados

Question

Eu tive problemas com o meu sistema (cabo de alimentação interno defeituoso). Quando eu coloquei o sistema novamente em funcionamento, arrays reconstruindo, etc, parece que tenho uma situação em que o comando pvs (e vgs e lvs ) relata No device found for PV <UUID> , mas o volume lógico que está no supostamente O volume físico ausente pode ser montado com sucesso, pois seus dispositivos DM existem e são mapeados em /dev/mapper .

O dispositivo PV é um array RAID10 md-raid, que parece bem, exceto pela confusão de que ele não está aparecendo na saída pvs .

Eu assumo que este é um problema com algumas tabelas internas que estão fora de sincronia. Como faço para que as coisas sejam mapeadas corretamente (sem uma reinicialização, o que, presumo, solucionaria)?

Atualização:

Uma reinicialização NÃO resolveu o problema. Acredito que o problema se deva à configuração do PV 'ausente' (/ dev / md99) como um array RAID10 far-2 construído a partir de um disco 750b (/ dev / sdk) e um array RAID0 (/ dev / md90) de um disco de 250GB (/ dev / sdh) e um disco de 500Gb (/ dev / sdl). Parece que da saída de pvscan -vvv que a assinatura lvm2 está localizada em / dev / sdh, mas não em / 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.

A única referência a / dev / md99, que deve ser o PV, é quando é adicionado ao cache do dispositivo.

Atualização 2:

Parar lvm2-lvmetad e repetir o pvscan confirma que o problema é que o sistema está confuso sobre quais PVs usar como se estivesse encontrando 2 com o mesmo 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

como essa configuração era apenas temporária, acho que seria melhor reorganizar meu uso de disco.

A menos que alguém possa me dizer como explicitamente substituir a ordem em que pvscan visualiza dispositivos?

    

Answer 1

O problema parece ser pvscan ficando confuso ao ver o mesmo UUID em um dispositivo de componente da matriz RAID e na própria matriz RAID. Eu suponho que isso é evitado normalmente, reconhecendo que o dispositivo é um componente direto. No meu caso, criei uma situação em que o dispositivo não era diretamente um componente do dispositivo RAID, que deveria ser o PV.

Minha solução foi fazer o backup dos LVs, forçar a degradação do array e reconfigurar os discos para não usar o RAID multinível. Observe que, após outra reinicialização, as letras do dispositivo foram alteradas. 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, i.e. 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

Moral da história:

Não introduza muitos níveis de indireção no sistema de arquivos!

    

Answer 2

A primeira coisa a verificar são as opções filter e global_filter em /etc/lvm/lvm.conf . Verifique se você não está filtrando os dispositivos em que seus PVs residem.

O cache é definido com a opção cache_dir no mesmo arquivo; na minha caixa Debian, o padrão é /run/lvm . O cache (se houver) deve estar nesse diretório. Se obtain_device_list_from_udev estiver definido, acredito que nenhum cache é usado.

Finalmente, verifique se use_lvmetad está definido. Em caso afirmativo, talvez seja necessário reiniciar o daemon de metadados do LVM.

    

Answer 3

Como root, esses comandos consertarão:

pvscan --cache
pvscan