Q: MDADM mismatch_cnt 0. Qualquer maneira de identificar quais blocos estão em desacordo?

Question

Ok. Depois de um scrub de rotina, meu MDADM RAID5 está relatando mismatch_cnt = 16. Pelo que entendi, isso significa que enquanto nenhum dispositivo relatou um erro de leitura, existem 16 blocos para os quais os dados e a paridade não estão de acordo.

Pergunta # 1: Pode-se obter uma lista desses blocos?

Pergunta # 2: Supondo que o número 1 é possível, dado que o sistema de arquivos subjacente é EXT4, existe uma maneira de identificar quais arquivos estão associados a esses blocos?

Eu tenho backups de nearline e, em um mundo ideal, eu poderia apenas diferenciar o array ao vivo dos dados de backup para localizar quaisquer arquivos que se tornaram silenciosamente corrompidos. Mas a realidade é recordar 6 TB de dados de backup seria proibitivamente caro e demorado. Saber onde procurar e o que recuperar simplificaria muito as coisas.

(Eu deveria notar que eu só executo o scrid RAID com a opção 'check'. Executar o scrub com a opção 'repair' parece terrivelmente perigoso porque o MDADM só sabe que os dados ou a paridade estão errados mas não Então, parece que há uma chance de 50% de que o MDADM ache errado e reconstrua dados incorretos. Daí meu desejo de saber quais arquivos são potencialmente afetados para que eu possa restaurá-los a partir do backup, se necessário)

Qualquer sugestão muito apreciada!

    

Answer 1

Desculpe, "verificar" realmente escreve de volta na matriz quando encontra um erro - consulte link

'check' is a read-only operation, even though the kernel logs may suggest otherwise (e.g. /proc/mdstat and several kernel messages will mention "resync"). Please also see question 21 of the FAQ.

If, however, while reading, a read error occurs, the check will trigger the normal response to read errors which is to generate the 'correct' data and try to write that out - so it is possible that a 'check' will trigger a write. However in the absence of read errors it is read-only.

... então talvez já seja tarde demais para coletar os dados que você está procurando, desculpe.

A longo prazo, vale a pena notar que o RAID5 (e 6, e 1) não têm nenhuma proteção contra a podridão de bits que provavelmente é a situação que você encontrou. Quando os dados de um disco são ruins, eles não têm como determinar quais dados são bons ou ruins. Eu sugeriria planejar migrar para um sistema de arquivos que verifica cada disco como btrfs ou zfs.

(o RAID-5 realmente não deve ser usado em novas implantações - e realmente não deve onde a capacidade de discos brutos é superior a 2 TB cada - veja link )