O disco rígido lê erros que… param?

Question

Minha história começa com simplicidade. Eu tenho um servidor leve, executando o Arch Linux, que armazena a maioria dos seus dados em um RAID-1 composto de 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 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) acessar o disco.

Eu verifiquei a saída 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 realmente estavam acontecendo há alguns dias, principalmente durante os backups, mas também frequentemente durante o uso muito leve (o que significa que a cada cinco tentativas eu tentei salvar um arquivo de texto). Eu concluí que meu disco estava morrendo, que o RAID-1 estava manipulando-o apropriadamente e que era hora de pedir 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 tomado o drive off-line, nada. Mas os erros acabaram de parar.

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

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

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

Então, a parte disso que está me incomodando é, claro, "Desde quando os discos ruins se consertam?"

Suponho que é possível que uma área muito pequena do drive tenha sido espontâneamente ruim e que o drive tenha levado 3 dias (!) antes de seu código de realocação do setor ser acionado e mapeado alguns setores sobressalentes em uma área ruim do disco ... Mas não posso dizer que já vi isso acontecer.

Alguém mais viu esse tipo de comportamento? Se sim, qual foi sua experiência com o disco depois? Isso aconteceu de novo? O disco eventualmente 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 mesmo assim. Mas eu adoraria saber se eu diagnosticasse isso de alguma forma. Se isso ajudar, eu tenho a saída 'smartctl -a' completa de quando o problema estava acontecendo. É um pouco longo, então não postei aqui.

    

Answer 1

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

Uma vez que os setores defeituosos são mapeados, e enquanto mais da superfície da unidade não falhar, você está em boa forma.

Eu não sei o suficiente sobre modelos de falha de unidade de unidades atuais para saber se há muita correlação entre uma parte da superfície da mídia que está indo mal e o problema se espalhando ou ocorrendo novamente. Se não houver correlação, quando os setores defeituosos forem mapeados, você estará em boa forma. Se existe uma correlação, então este é o começo do fim da unidade.

    

Answer 2

A maioria das unidades modernas irá "vectorar" um bloco que foi mal. A unidade possui um conjunto de blocos de reserva e o firmware os utiliza para substituir os blocos que são conhecidos pela unidade como ruins. A unidade não pode fazer esse mapeamento quando falhar em ler um bloco porque ele não pode fornecer os dados corretos. Apenas retorna "erro de leitura". Ele MARCA o bloco como ruim, portanto, se o bloco for lido corretamente, o bloco será vetorizado e os dados corretos serão gravados no bloco de substituição. Se o SO alguma vez ESCREVER em um bloco que está em um estado de "vetor pendente", então o bloco é vetorizado e os dados gravados no bloco de substituição.

Linux software raid irá, ao obter um erro de leitura de um dispositivo, obter os dados corretos de outros elementos na matriz e, em seguida, ele tenta gravar o bloco defeituoso novamente. Então, se a gravação funciona OK, então os dados são seguros, se não, a unidade apenas faz o acima, vectores do bloco e, em seguida, executar a gravação. Então, a unidade tem, com a ajuda do sistema de ataque, apenas reparado em si!

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 de reserva e isso é uma função da unidade.

    

Answer 3

Sim, também vi isto e em circunstâncias muito semelhantes. No meu caso, foi uma unidade "verde" de 1 TB "Western Digital" de consumo (WD10EARS) que puxou esse truque para mim. O valor bruto Current_Pending_Sector do SMART foi de zero para 6 e, em seguida, para 8, solicitando que o daemon de monitoramento SMART me enviasse alguns e-mails ameaçadores.

Eu mdadm --fail ed e --remove d a unidade da matriz e executei uma passagem não destrutiva de badblocks sobre ela, e sim, aparentemente havia mais de duas dúzias de blocos defeituosos. Quando a unidade de substituição chegou cerca de um dia depois, consertei a matriz e a vida continuou.

Pouco depois, por puro tédio, reran badblocks no disco "falhou" para ver se ele havia piorado. Pelo contrário, o disco tinha se "consertado" completamente: zero blocos ruins! Balançando a cabeça, limpei e guardei para ser reciclado ou doado.

A lição: não use discos de nível de consumidor em servidores, a menos que você esteja disposto e seja capaz de suportar todo tipo de estranheza e insegurança. Corolário: Não seja barato em componentes de servidor, porque você acabará pagando por eles de qualquer maneira, no tempo extra e no agravamento.

    

Answer 4

É uma prática comum em ambientes de servidor descartar unidades que já mostraram tais erros, corrigidos ou não. Os erros duros do setor podem ser um sinal de danos físicos à superfície do meio - e se você riscar uma superfície, normalmente você desloca o material para os lados do arranhão e obtém uma broca mais alta do que o plano da superfície - ou pó abrasivo (vidro! ). Ambos tendem a ser bastante prejudiciais para um sistema mecânico que depende de uma almofada de ar muito fina entre duas superfícies assumidas perfeitamente lisas ... é por isso que erros médios, quando começam a atingir uma determinada contagem, tendem a se multiplicar mais rapidamente.