recupera um disco raid que aparentemente não tem erros

Question

Já há vários anos rodamos um software RAID1 em uma velha caixa do Gentoo com um Linux 2.6.31 customizado. O RAID consiste em 2 discos rígidos com 4 partições cada. Nos últimos anos, aconteceu cerca de 3-4 vezes que um disco foi jogado fora do array. Mas cada vez que badblocks não reportou um erro e eu consegui reativar o disco assim

mdadm /dev/md3 -r /dev/sda3
mdadm /dev/md3 -a /dev/sda3

Desta vez, a situação é diferente: mdadm relatou 2 partições defeituosas nas últimas 24 h, ambas no mesmo disco sda . Mais uma vez eu corri badblocks sem sucesso: ele relatou 0 blocos ruins. Se eu tentar adicionar o disco com defeito de volta ao array, ele quebrará o mesmo erro toda vez:

Mar 25 23:09:10 xen0 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Mar 25 23:09:10 xen0 kernel: ata1.00: irq_stat 0x40000001
Mar 25 23:09:10 xen0 kernel: ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Mar 25 23:09:10 xen0 kernel: res 51/04:00:38:df:f7/00:00:00:00:00/a7 Emask 0x1 (device error)
Mar 25 23:09:10 xen0 kernel: ata1.00: status: { DRDY ERR }
Mar 25 23:09:10 xen0 kernel: ata1.00: error: { ABRT }
Mar 25 23:09:10 xen0 kernel: ata1.00: configured for UDMA/133
Mar 25 23:09:10 xen0 kernel: ata1: EH complete
Mar 25 23:09:10 xen0 kernel: end_request: I/O error, dev sda, sector 18297870
Mar 25 23:09:10 xen0 kernel: md: super_written gets error=-5, uptodate=0
Mar 25 23:09:10 xen0 kernel: md: md3: recovery done.
Mar 25 23:09:10 xen0 kernel: RAID1 conf printout:
Mar 25 23:09:10 xen0 kernel: --- wd:1 rd:2
Mar 25 23:09:10 xen0 kernel: disk 0, wo:1, o:0, dev:sda3
Mar 25 23:09:10 xen0 kernel: disk 1, wo:0, o:1, dev:sdb3
Mar 25 23:09:10 xen0 kernel: RAID1 conf printout:
Mar 25 23:09:10 xen0 kernel: --- wd:1 rd:2
Mar 25 23:09:10 xen0 kernel: disk 1, wo:0, o:1, dev:sdb3

O setor é sempre o mesmo: 18297870 . Se eu verificar a saída de smartctl -a /dev/sda não mostra quaisquer setores realocados, então eu pensei, eu poderia impor realocação com um método que encontrei aqui .

hdparm --read-sector  18297870 /dev/sda
hdparm --write-sector  18297870 --yes-i-know-what-i-am-doing /dev/sda

Mas com os comandos acima, o disco não relata nenhum erro - e, portanto, não realoca o setor:

smartctl -a /dev/sda | grep -i reall
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0

Eu pesquisei a mensagem status: { DRDY ERR } e alguns dizem que isso pode ser um bug do kernel. Mas então eu me pergunto por que isso só começou a acontecer agora. Não houve mudança no sistema nos últimos anos.

Há uma coisa que ainda me incomoda: smartctl -a /dev/sda também relata alguns erros nos logs. É sempre o mesmo erro:

Error 15 occurred at disk power-on lifetime: 39971 hours (1665 days + 11 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  04 51 00 38 df f7 a7

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ea 00 00 00 00 00 00 08  35d+12:17:45.571  FLUSH CACHE EXT
  61 80 f0 0e 96 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 e8 8e 95 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 e0 0e 95 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED
  61 80 d8 8e 94 2d 00 08  35d+12:17:44.033  WRITE FPDMA QUEUED

Tudo isso não faz sentido para mim: se o disco está realmente com defeito, por que posso ler e gravar com sucesso no setor em que a ressincronização de RAID falha a cada vez? E por que o disco não tenta primeiro realocar o setor quebrado se ele realmente detectar um erro?

    

Answer 1

Esta pergunta pergunta como recuperar uma unidade que um RAID caiu e pergunta como uma unidade pode periodicamente ser excluída de um RAID quando problemas de setor não existem. Para começar a entender o que pode estar acontecendo, pode ser útil perceber que é completamente plausível que as unidades entrem em uma função de recuperação ou calibração de erros a longo prazo e não respondam por um período de tempo suficiente que um controlador RAID falhará. a unidade, mesmo que não tenha erros de mídia.

Se a unidade não foi projetada para uso em um RAID, uma operação periódica de autoteste pode ser suficiente para causar falha na unidade. Este parágrafo faz referência ao assunto:

link

Este link de bug de 49 dias descreve uma ocorrência notória de falhas de RAID induzidas por TLER.

Unidades especificamente projetadas para RAID limitam o tempo que o inversor pode ficar offline para realizar operações de manutenção / recuperação.

Ao comprar uma unidade para uso em um RAID, e para evitar problemas dessa natureza, é útil procurar a recuperação de erros com tempo limitado ( TLER ) na especificação da unidade.

O problema do TLER não explica a dificuldade em reconstruir a matriz, no entanto, considere uma situação em que uma unidade sustenta uma falha do setor e o firmware da unidade remapeia o setor com falha para um sobressalente para que a unidade continue "perfeita" . Pode-se perguntar se o setor de 18297870 foi remapeado para um setor de reposição e os acessos ao setor de reposição demoram demais por algum motivo. Isso parece um pouco improvável, mas saber que os atrasos no tempo de acesso ao disco podem causar estragos com os RAIDs pode ser a chave para descobrir o que está acontecendo.

Verifique se há atualizações de firmware emitidas pelo fabricante para as unidades. As atualizações de firmware geralmente não estão disponíveis para unidades de classe de consumidor, mas as unidades de classe de servidor geralmente recebem atualizações de firmware que corrigem bugs de firmware que causam problemas operacionais, mesmo quando uma falha de hardware não ocorreu. Uma pesquisa na Web pelos termos "eliminação de RAID do erro do firmware da unidade" produz muitos resultados pertinentes. Alguns resultados identificam marcas e modelos específicos de unidades.

Este link documenta uma instância de um firmware deficiência que causou falha no RAID. Embora não seja idêntico ao problema documentado acima, o artigo mostra a relevância do firmware como agente causador de problemas de RAID. Consulte também a página da Wikipedia Seagate Barracuda que contém muitas referências para erros de firmware que causam problemas de desempenho.