Início / unix / Perguntas / 730307
Accepted
std_unordered_map
Asked: 2023-01-03 05:13:16 +0800 CST

Encontre o(s) arquivo(s) contido(s) no setor de um array raid

  • 772

Hoje, verifiquei meu array raid6 (com sistema de arquivos ext4) e duas mensagens do kernel apareceram:

mismatch sector in range 2842495632-2842495640
mismatch sector in range 2927793488-2927793496

A partir de agora, tem sido impossível para mim pesquisar no Google qualquer coisa útil sobre como posso descobrir quais arquivos (se houver) residem nesses setores.

Talvez isso explique melhor o que estou perguntando: Dada uma utilidade hipotética, find-filequero ligar find-file 2842495632e obter uma resposta como /mnt/raid/this-file-has-a-mismatch.

linux

1 respostas

  1. Best Answer

    Isenção de responsabilidade:
    tudo pode estar errado, estou em águas profundas aqui e é fácil cometer um erro, mas é difícil verificar se você está correto. Estou assumindo que os setores relatados são todos de 512 bytes. Há também compensações que podem estar erradas.
    Espero ter acertado o suficiente, mas o tempo dirá. Se você encontrar um erro, por favor me corrija!
    Todos os comandos precisam de privilégios de root para serem executados. Backups são sempre bons.

    Fundo

    Estou lutando com o mesmo problema que você. Metade das unidades em um RAID6 desapareceu devido a uma placa controladora de disco quebrada. Não é bom. Agora tenho 48 setores MD com incompatibilidade e quero descobrir quais arquivos podem estar armazenados lá. Minha configuração é semelhante à sua, mas também tenho LVM no mix.

    Esta resposta é para minha configuração porque acho que muitos também usam LVM e você não apresentou tantos detalhes de sua configuração. Este também foi o único que pude testar.
    No seu caso, apenas pule as partes do LVM. Se você tiver o array md particionado, também terá que encontrar o deslocamento para o seu sistema de arquivos. Em ambos os casos, deve dar-lhe pelo menos algumas ideias.

    A Configuração

    A configuração de armazenamento é a seguinte:
    Mdraid RAID6 em 6 unidades SATA como /dev/md1. Esta matriz é usada como PV para um grupo de volume LVM2 “vg_arch”. No VG existem vários LVs, um deles é “lv_arch2” formatado como Ext4.

    Então temos: HDD→MD→LVM→Ext4

    O problema

    Depois de executar uma verificação em sua matriz mdraid ( /usr/share/mdadm/checkarray -a /dev/md1), você encontrou linhas como esta em /var/log/syslog:

    Jan  4 03:28:28 orion kernel: [36199.659889] md1: mismatch sector in range 2684449552-2684449560
Jan  4 03:28:28 orion kernel: [36199.659897] md1: mismatch sector in range 2684449560-2684449568
Jan  4 03:28:28 orion kernel: [36199.659901] md1: mismatch sector in range 2684449568-2684449576
Jan  4 03:28:28 orion kernel: [36199.659904] md1: mismatch sector in range 2684449576-2684449584
Jan  4 03:28:28 orion kernel: [36199.659921] md1: mismatch sector in range 2684449584-2684449592
Jan  4 03:28:28 orion kernel: [36199.659925] md1: mismatch sector in range 2684449592-2684449600

    O problema aqui é que alguns blocos na matriz RAID estão corrompidos e os dados não são confiáveis. O número de razões diferentes para isso é quase ilimitado, mas os setores são ruins e agora temos que descobrir se algum arquivo está armazenado lá e, em caso afirmativo, quais arquivos.
    No meu caso, a matriz foi dividida em 50/50, portanto, era impossível para o mdraid saber quais dados usar.

    A gama de setores defeituosos é 2684449552 – 2684449600, 48 no total.

    É bom ler primeiro sobre a recuperação de RAID e usar sobreposições ao tentar recuperar para não destruir seus dados. É super fácil destruir tudo.

    Presumo que você tenha sua matriz montada e funcionando, pelo menos no modo somente leitura. Usei sobreposições ao testar, então não escrevi nada no array real por engano. Somente acesso somente leitura é necessário para este guia.

    A caça ao setor

    Para começar, o número do setor que obtivemos do kernel é o setor do array md (pelo menos essa é minha suposição). Isso é bom porque não precisamos levar em consideração os níveis mais baixos da pilha de armazenamento (compensações de partição, etc.) e isso torna tudo um pouco mais fácil.

    Este é o caminho que devemos seguir: HDD→MD→LVM→Ext4→arquivo

    LVM

    Já estamos no nível MD, agora precisamos olhar para o LVM.

    Na parte inferior da pilha LVM estão os volumes físicos (PVs). Estes são divididos em extensões e uma ou mais extensões compõem um volume lógico (LV). Os volumes físicos são apenas o dispositivo subjacente, portanto, neste caso, são /dev/md1.

    Os dados em um PV não começam diretamente no setor 0, mas possuem um deslocamento. Os primeiros setores são usados ​​para metadados LVM. Primeiro temos que descobrir a que distância no PV as extensões começam:

    # pvs --noheadings -o pe_start --units s /dev/md1
2048S

    Os dados começam em 2048 setores no PV. Os setores problemáticos começam em 2684449552-2048 = 2684447504setores no LVM e terminam em 2684449600-2048 = 335555944.

    Em seguida, precisamos saber o tamanho de uma extensão LVM:

    # pvdisplay --units s /dev/md1 | grep 'PE Size'
PE Size               8192 Se

    Temos 8192 setores por extensão LVM.

    Agora podemos calcular em que medida o problema começa:2684447504/8192 = 327691,345703125 extents

    É uma fração porque o setor não está em um limite PE exato. O restante nos dará o deslocamento do setor no PE: 0,345703125*8192 = +2832 sectors

    Próximo passo é tentar descobrir qual LV que está usando o PE 327691:

    # pvdisplay --maps /dev/md1 | grep -A1 'Physical extent'
  Physical extent 0 to 2621439:
    Logical volume  /dev/vg_arch/lv_arch2
--
  Physical extent 2621440 to 3801087:
    Logical volume  /dev/vg_arch/lv_test

    Podemos ver que o PE pertence a LV /dev/vg_arch/lv_arch2e que não tem offset. Se tiver um offset, temos que levar isso em consideração.

    FS Ext4

    Agora temos informações suficientes para irmos para o nível do sistema de arquivos. Primeiro temos que saber com quais tamanhos de setor/bloco estamos trabalhando:

    # fdisk -u -l /dev/md1
Disk /dev/md1: 14.52 TiB, 15959456743424 bytes, 31170813952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 1048576 bytes / 4194304 bytes

    A matriz md está usando setores de 512 bytes (estou um pouco inseguro se isso está correto ou não. Estou basicamente assumindo que o kernel usa o mesmo tamanho de setor ao relatar o erro).

    Para obter o tamanho do bloco Ext4:

    # tune2fs -l /dev/vg_arch/lv_arch2 | grep Block
Block count:              2684354560
Block size:               4096

    O sistema de arquivos usa blocos de 4KiB que equivalem a 8 setores por bloco.

    Agora temos que traduzir o número do setor mdadm para o número do bloco Ext4 porque eles não são os mesmos. Para fazer isso, podemos usar esta fórmula:

    (mdadm sector number) / ((filesystem block size) / (mdadm sector size)) = Ext4 block number

    Neste caso temos:

    2684447504 / (4096 / 512) = 335555938 (start)
2684447552 / (4096 / 512) = 335555944 (stop)

    Portanto, o intervalo de blocos problemático é 335555938 a 335555944 no sistema de arquivos Ext4.

    Verificação de arquivo

    Quando tivermos os números dos blocos, podemos tentar encontrar o arquivo armazenado lá. Isso pode ser feito usando debugfs.

    # debugfs
debugfs:

    Em seguida, no debugfsconsole, use o comando open para abrir o sistema de arquivos (ele ainda não deve estar montado):

    debugfs:  open /dev/vg_arch/lv_arch2

    Esta operação pode levar algum tempo se você tiver um sistema de arquivos grande.

    Agora podemos começar a testar se os blocos são usados ​​ou não. Se tivermos sorte, os bad blocks não serão usados ​​por nenhum arquivo. Use testb blocknumberpara testá-lo.

    debugfs:  testb 335555938
Block 335555938 not in use

    Repita este comando para cada bloco ruim que você tiver e registre os usados, assim:

    debugfs:  testb 335555944
Block 335555944 marked in use

    Se todos os blocos não forem usados, você estará pronto. Parabéns! Caso contrário, teremos que continuar a encontrar os arquivos afetados.

    O próximo passo é encontrar o inode que está usando este bloco:

    debugfs:  icheck 335555944
Block   Inode number
335555944   279577043

    Portanto, temos um inode 279577043 afetado, vamos encontrar o nome do arquivo:

    debugfs:  ncheck 279577043
Inode   Pathname
279577043   /my_files/file.dat

    Finalmente, encontramos o arquivo afetado pelos setores mdadm quebrados. Isso não foi muito difícil. ;-)

    Para finalizar, execute os comandos closee quitpara sair debugfs.

    Fontes

    Foi difícil encontrar informações sobre esse problema, mas aqui estão os sites que mais usei:

    • 2

relate perguntas