Como posso verificar se há blocos defeituosos em um volume físico LVM?

Question

Quando você estiver usando o ext4, poderá verificar os badblocks com o comando e2fsck -c /dev/sda1 # or whatever . Isto irá "colocar na lista negra" os blocos, adicionando-os ao inode do bloco defeituoso.

Qual é o equivalente disto para um volume físico LVM2? O sistema de arquivos nele é ext4, mas presumivelmente, os blocos defeituosos detectados se tornarão inválidos à medida que a configuração do LVM subjacente movimenta os dados no disco físico.

Em outras palavras, como eu posso verificar se há blocos ruins para não usar no LVM?

    

Answer 1

When you're using ext4, you can check for badblocks with the command e2fsck -c /dev/sda1 or whatever. This will "blacklist" the blocks by adding them to the bad block inode.

e2fsck -c runs badblocks no disco rígido subjacente. Você pode usar o comando badblocks diretamente em um volume físico LVM (supondo que o PV seja de fato um disco rígido, e não algum outro tipo de dispositivo virtual como um dispositivo RAID de software MD), da mesma forma que você usaria esse comando um disco rígido que contém um sistema de arquivos ext.

Isso não adicionará nenhum tipo de informação de bloqueio ruim ao sistema de arquivos, mas eu não acho que esse seja um recurso útil do sistema de arquivos; o disco rígido deve manipular blocos ruins.

Ainda melhor do que badblocks está executando um autoteste SMART no disco (substitua /dev/sdX pelo nome do dispositivo do seu disco rígido):

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

O teste ifself levará algumas horas (ele dirá exatamente quanto tempo). Quando estiver pronto, você pode consultar o resultado com smartctl -a , procure o log de autoteste. Se disser "Completed successfully", o seu disco rígido está bem.

In other words, how can I check for bad blocks to not use in LVM?

Como eu disse, o próprio disco rígido irá garantir que ele não use blocos danificados e também realocará os dados desses blocos; isso não é algo que o sistema de arquivos ou o LV precisa fazer. Por outro lado, quando seu disco rígido tem mais do que apenas alguns blocos defeituosos, você não quer algo que os realoque, mas deseja substituir todo o disco rígido porque está falhando.

    

Answer 2

Tenho certeza que o LVM não lida com blocos ruins; espera o armazenamento subjacente para. E a maioria, se não todos, os discos rígidos modernos. Talvez seja necessário executar uma gravação no setor, mas o disco deve remapá-lo. (Você pode precisar fazer uma verificação de superfície off-line primeiro, por exemplo, smartctl /dev/sda -t offline ).

Dito isso, o LVM não move os dados, a menos que você os solicite, por exemplo, pvmove . Então você pode usar o recurso de badblocks ext4; você só precisará verificar novamente se há blocos ruins se executar pvmove . Nenhuma operação comum (como lvextend ) move dados.

Extend não move dados porque o LVM mantém um mapa dizendo "extensões lógicas 0-99 são extensões físicas de 200 a 299" e, quando você as estende, adiciona apenas "extensões lógicas de 100 a 199 são extensões físicas de 100 a 199 ". Ou até mesmo "extensões lógicas 100-149 são extensões físicas 50-99; extensões lógicas 150-199 são extensões físicas 140-189". O LVM não se importa que as extensões físicas não estejam em ordem ou não sejam contíguas.

    

Answer 3

pvck pode verificar os metadados do LVM, depois que a consistência é o trabalho do sistema de arquivos. O LVM é apenas sobre gerenciamento de volume, portanto, não precisa se preocupar se o espaço que constitui uma determinada extensão é ruim, já que softwares de nível mais alto capturam esses problemas. Metadados LVM só ocupam o primeiro (opcionalmente também o último setor) do volume físico de qualquer maneira.

Se apenas o primeiro e o último setor de um PV razoavelmente grande (como o que você vê na produção) simplesmente falha ao mesmo tempo, basicamente você tem a maior sorte do mundo, já que isso é tão improvável em termos astronômicos. Caso contrário, se o administrador souber que vários setores da unidade falharam, a maioria das pessoas está certa, apenas arquivando coisas como essa em "o disco rígido falhou permanentemente e precisa ser substituído".

Se pvck retornar um erro, você poderá verificar se os metadados de seu LVM foram submetidos a backup em /etc/lvm em algum lugar. Se é você pode fazer pvcreate especificando a cópia de backup para --restorefile

Sintaxe:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Exemplo:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

Se a restauração não funcionar (por exemplo, se o primeiro setor for ruim), você pode refazer o que foi mencionado acima, mas defina --metadatacopies 2 (ou você pode ir direto a isso), que tentará escrever os metadados para o primeiro e último setores no PV. Quando pvscan faz o seu trabalho na inicialização, ele verifica os dois locais e, se encontrar metadados, ele os verificará em uma soma de verificação. Se a soma de verificação falhar no primeiro setor, mas for bem-sucedida no último setor, você receberá uma mensagem de erro não fatal.

Mais ou menos manual e doloroso, mas, novamente, isso é parte da razão pela qual as pessoas estão empolgadas para obter um novo gerenciamento de volume com o BTRFS. Na maioria das vezes, não é tanto um problema pelas razões mencionadas, e porque as pessoas que absolutamente precisam garantir a continuidade dos dados geralmente fazem RAID e têm uma estratégia de backup.