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

Quando você estiver usando ext4, você pode verificar se há badblocks com o comando e2fsck -c /dev/sda1 # or whatever. Isso fará uma "lista negra" dos blocos, adicionando-os ao inode do bloco inválido.

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

Em outras palavras, como posso verificar se há blocos defeituosos para não serem usados ​​no LVM?

Ao usar o ext4, você pode verificar se há badblocks com o comando e2fsck -c /dev/sda1ou o que seja. Isso fará uma "lista negra" dos blocos, adicionando-os ao inode do bloco inválido.

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

Isso não adicionará nenhum tipo de informação de bloco inválido ao sistema de arquivos, mas eu realmente não acho que esse seja um recurso útil do sistema de arquivos; o disco rígido deve lidar com blocos defeituosos.

Ainda melhor do que a badblocksexecução de um autoteste SMART no disco (substitua /dev/sdXpelo nome do dispositivo do seu disco rígido):

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

O teste levará algumas horas (será informado exatamente quanto tempo). Quando terminar, você poderá consultar o resultado smartctl -ae procurar o log de autoteste. Se aparecer "Concluído com sucesso", seu disco rígido está bom.

Em outras palavras, como posso verificar se há blocos defeituosos para não serem usados ​​no LVM?

Como eu disse, o próprio disco rígido garantirá que 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 precise fazer. Por outro lado, quando seu disco rígido possui mais do que apenas alguns blocos defeituosos, você não deseja algo que os realoque, mas deseja substituir todo o disco rígido porque está falhando.

Tenho certeza de que o LVM não lida com blocos defeituosos; espera o armazenamento subjacente para. E a maioria, se não todos, os discos rígidos modernos. Pode ser necessário gravar no setor, mas o disco deve remapear. (Pode ser necessário primeiro fazer uma varredura offline da superfície, por exemplo, smartctl /dev/sda -t offline).

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

A extensão não move dados porque o LVM mantém um mapa dizendo "extensões lógicas 0–99 são extensões físicas 200–299" e, quando você as estende, adiciona apenas "extensões lógicas 100–199 são extensões físicas 100–199". Ou 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.

pvckpode 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 extensão específica é ruim, pois o software de nível superior captura esses problemas. Os metadados do LVM ocupam apenas o primeiro (opcionalmente também o último setor) do volume físico.

Se apenas o primeiro e o último setor de um PV razoavelmente grande (como você veria em produção) falharem simultaneamente, você basicamente tem a pior sorte do mundo, uma vez que isso é astronomicamente improvável. Caso contrário, se o administrador souber que vários setores da unidade estão falhando, a maioria das pessoas está bem apenas arquivando coisas como esta em "o disco rígido falhou permanentemente e precisa ser substituído".

Se pvckretornar um erro, você poderá verificar se os metadados do LVM estão armazenados em /etc/lvmalgum lugar. Se for, você pode pvcreateespecificar 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 estiver ruim), você poderá refazer o --metadatacopies 2procedimento acima, mas defina (ou você pode ir direto ao assunto) que tentará gravar os metadados no primeiro e últimos setores no PV. Quando pvscanele faz a inicialização, ele verifica os dois locais e, se encontrar metadados, os verifica 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.

Tipo de manual e uma dor, mas, novamente, isso é parte da razão pela qual as pessoas estão animadas para obter um redux de gerenciamento de volume com o BTRFS. Na maioria das vezes, não é realmente um problema tão grande pelos motivos mencionados abaixo, e porque as pessoas que precisam absolutamente positivamente de garantir a continuidade dos dados geralmente fazem RAID e têm uma estratégia de backup.