P: MDADM mismatch_cnt> 0. Alguma maneira de identificar quais blocos estão em desacordo?

OK. Após uma limpeza de rotina, meu MDADM RAID5 está relatando mismatch_cnt = 16. Pelo que entendi, isso significa que, embora nenhum dispositivo tenha relatado um erro de leitura, existem 16 blocos para os quais os dados e a paridade não concordam.

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

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

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

(Devo observar que eu só executo o scrid RAID com a opção 'check'. Executar o scrub com a opção 'repair' parece muito perigoso porque o MDADM sabe apenas que os dados ou a paridade estão errados, mas não sabe qual. Portanto, parece que há uma chance de 50% de que o MDADM adivinhe errado e reconstrua dados incorretos. Portanto, meu desejo de saber quais arquivos são potencialmente afetados para que eu possa restaurá-los do backup, se necessário)

Todas as sugestões muito apreciadas!

linux mdadm

— arcasinky
fonte

verificar dmesgou / var / log / syslog?

— Psusi

Oi. Pelo que sei, as únicas mensagens registradas no syslog pelo depurador foram as mensagens de início e parada. Nenhuma mensagem sobre incompatibilidades foi registrada.

— Arcsinky

Veja icheck+ ncheckin debugfspara identificar arquivos com base no deslocamento do setor.

— SCH

Tentei adicionar o log para o número do setor. Agora eu estou tentando descobrir o que fazer a seguir: unix.stackexchange.com/questions/266432/...

— Peter Cordes

Eu sei que nada diz que os discos são ruins, mas verifique-os. Use o pacote smartmontools para fazer isso para cada disco (como em smartctl -a /dev/sdaoutros), ou use qualquer outro método para executar um teste SMART curto em cada disco e imprimir um relatório completo. É muito provável que um deles esteja morrendo, e é preciso muito dano para acionar um alarme geral de saúde SMART.

— Spooler

Desculpe, 'check' realmente grava de volta na matriz quando encontra um erro - consulte https://www.apt-browse.org/browse/ubuntu/trusty/main/amd64/mdadm/3.2.5-5ubuntu4/file /usr/share/doc/mdadm/README.checkarray

'check' é uma operação somente leitura, mesmo que os logs do kernel possam sugerir o contrário (por exemplo, / proc / mdstat e várias mensagens do kernel mencionarão "resync"). Consulte também a pergunta 21 das perguntas frequentes.

Se, no entanto, durante a leitura, ocorrer um erro de leitura, a verificação acionará a resposta normal para erros de leitura, que é gerar os dados 'corretos' e tentar escrevê-los - para que seja possível que uma 'verificação' escrever. No entanto, na ausência de erros de leitura, é somente leitura.

... portanto, 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 tem proteção contra a rotação de bits, o que provavelmente é a situação que você encontrou. Quando os dados de um disco ficam danificados, eles não têm como determinar qual deles é bom ou ruim. Eu sugeriria o planejamento da migração para um sistema de arquivos que soma as somas de cada disco, como btrfs ou zfs.

(O RAID-5 realmente não deve ser usado em novas implantações - e realmente não deveria, onde a capacidade dos discos brutos é superior a 2 TB cada - consulte http://www.zdnet.com/article/why-raid-5- pára de trabalhar em 2009 / )

— Andrew W
fonte