Erros de leitura do disco rígido que… param?

Minha história começa de maneira bastante simples. Eu tenho um servidor leve, executando o Arch Linux, que armazena a maioria dos dados em um RAID-1 composto por duas unidades SATA. Ele estava funcionando sem problemas por cerca de 4 meses. Então, de repente, comecei a receber erros de leitura em uma das unidades. Sempre, as mensagens se pareciam muito com estas:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Cada erro reclamou de um número de setor diferente e foi acompanhado por um atraso de vários segundos para o usuário (eu) acessando o disco.

Verifiquei a saída do smartctl e vi a seguinte saída (peças irrelevantes cortadas):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Olhando para trás nos logs, descobri que os erros já estavam ocorrendo há alguns dias, principalmente durante backups, mas também frequentemente durante um uso muito leve (ou seja, a cada 5 vezes que eu tentava salvar um arquivo de texto). Concluí que meu disco estava morrendo, que o RAID-1 estava manipulando-o adequadamente e que estava na hora de solicitar um disco de substituição. Eu pedi um novo disco.

Para minha surpresa, um dia depois, os erros ... pararam. Eu não fiz nada para consertá-los. Eu não tinha reiniciado, não tinha colocado a unidade offline, nada. Mas os erros simplesmente pararam.

Nesse momento, curioso para ver se os setores defeituosos estavam apenas em partes ociosas do disco agora, tirei o disco do RAID, coloquei-o novamente no RAID e permiti que ele concluísse a ressincronização completa subsequente. A ressincronização foi concluída sem erros, 9 horas depois (os discos de 2 TB demoram um pouco).

Além disso, a saída do smartctl mudou um pouco, da seguinte maneira:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Portanto, a parte disso que me incomoda é, é claro, "desde quando os discos ruins se consertam?"

Suponho que seja possível que uma área muito pequena da unidade tenha espontaneamente danificado e que a unidade tenha levado apenas três dias (!) Antes que seu código de realocação do setor seja ativado e mapeie alguns setores sobressalentes sobre uma área defeituosa do disco ... Mas não posso dizer que já vi isso acontecer.

Alguém mais viu esse tipo de comportamento? Em caso afirmativo, qual foi sua experiência com a unidade depois? Isso aconteceu de novo? O disco finalmente falhou completamente? Ou foi apenas uma falha inexplicável que permaneceu inexplicável?

No meu caso, eu já tenho a unidade de substituição (obtida na garantia), então provavelmente substituirei a unidade de qualquer maneira. Mas eu adoraria saber se diagnosticou isso de alguma forma. Se ajudar, tenho uma saída 'smartctl -a' completa a partir de quando o problema estava acontecendo. É um pouco longo, então eu não postei aqui.

Se uma região física específica da superfície da unidade ficar ruim, até que esses setores possam ser mapeados com sucesso, você obterá erros de leitura não recuperados ao tentar ler quaisquer dados que foram gravados nessa área. A unidade sabe que os setores são ruins (após as falhas de acesso aos setores), mas não pode remapear os setores porque eles já contêm dados. Se você formatar a unidade ou substituir os setores "defeituosos", a unidade terá a oportunidade de mapear os setores defeituosos.

Depois que os setores defeituosos são mapeados, e enquanto a superfície da unidade não falhar, você estará em boa forma.

Não sei o suficiente sobre os modelos de falha de unidades atuais para saber se há muita correlação entre uma parte da superfície da mídia ficar ruim e o problema se espalhar ou ocorrer novamente. Se não houver correlação, depois que os setores defeituosos forem mapeados, você estará em boa forma. Se não é uma correlação, então este é o começo do fim para a unidade.

A maioria das unidades modernas "vectoria" um bloco que deu errado. A unidade possui um conjunto de blocos sobressalentes e o firmware os utiliza para substituir todos os blocos que são considerados defeituosos. A unidade não pode fazer esse mapeamento novamente quando falha em LER um bloco, porque não pode fornecer os dados corretos. Apenas retorna "erro de leitura". MARCA o bloco como ruim; portanto, se o bloco for lido corretamente, o vetor será retirado do vetor e os dados corretos gravados no bloco de substituição. Se o SO alguma vez ESCREVER em um bloco que esteja no estado "vetor pendente", o bloco será vetorizado e os dados gravados no bloco de substituição.

A invasão do software Linux, ao obter um erro de leitura de um dispositivo, obtém os dados corretos de outros elementos da matriz e tenta gravar novamente o bloco defeituoso. Portanto, se a gravação funcionar bem, os dados estarão seguros; caso contrário, a unidade fará o que foi descrito acima, vetores do bloco e, em seguida, executa a gravação. ASSIM, a unidade, com a ajuda do sistema de invasão, apenas se reparou!

Supondo que tais eventos sejam razoavelmente raros, provavelmente é seguro continuar. Se muitos blocos de substituição estiverem sendo usados, a unidade poderá ter um problema. Há um limite para quantos blocos de substituição podem ser vetorizados para blocos sobressalentes e isso é uma função do inversor.

Sim, eu já vi isso também, e em circunstâncias muito semelhantes. No meu caso, foi uma unidade Western Digital de 1 TB "Green" (WD10EARS) da Western Digital de "consumo" que me atraiu. O Current_Pending_Sectorvalor bruto do SMART passou de zero para 6 e depois para 8, solicitando que o daemon de monitoramento SMART me enviasse alguns e-mails ameaçadores.

I mdadm --failEd e --removed a unidade da matriz e correu uma passagem não-destrutiva de badblockssobre ele, e sim, havia, aparentemente, mais de 2 dúzia de blocos danificados. Quando a unidade de substituição chegou, um dia depois, consertei a matriz e a vida continuou.

Pouco tempo depois, por puro tédio, voltei badblocksà unidade "falhada" para ver se havia piorado. Pelo contrário, a unidade havia se "consertado" completamente: zero blocos ruins! Balançando a cabeça, limpei e reservei para ser reciclado ou doado.

A lição: não use unidades de consumo nos servidores, a menos que você esteja disposto e seja capaz de suportar todo tipo de estranheza e falta de confiabilidade. Corolário: não se preocupe com os componentes do servidor, porque você acabará pagando por eles de qualquer maneira, em tempo extra e agravamento.

É prática comum em ambientes de servidor descartar unidades que já apresentaram esses erros, corrigidos ou não. Erros graves no setor podem ser um sinal de dano físico à superfície - e se você arranhar uma superfície, normalmente desloca o material para as laterais do arranhão e fica com uma rebarba mais alta que o plano dessa superfície - ou poeira abrasiva (vidro! ) Ambos tendem a ser bastante prejudiciais para um sistema mecânico que se baseia em uma almofada de ar muito fina entre duas superfícies consideradas perfeitamente suaves ... é por isso que erros médios quando começam a atingir uma certa contagem tendem a se multiplicar mais rapidamente.