☰

Como ignorar um erro SMART específico

tag-icon • tag-icon unix hard-drive smart
Como ignorar um erro SMART específico

Recebo um e-mail sobre o mesmo erro SMART todos os dias. Gostaria de configurar o daemon SMART para ignorar esse erro específico, mas apenas isso, já que ainda quero fazer isso agora se alguma coisa mudar ou piorar.

This email was generated by the smartd daemon running on:

 host name: jon
DNS domain: [Unknown]
NIS domain: (none)

The following warning/error was logged by the smartd daemon:

Device: /dev/sdb [SAT], 11 Currently unreadable (pending) sectors


For details see host's SYSLOG.

You can also use the smartctl utility for further investigation.
The original email about this issue was sent at Sun Nov 25 02:30:45 2012 CET
Another email message will be sent in 24 hours if the problem persists.

Quando isso aconteceu pela primeira vez, o número de setores ilegíveis estava aumentando lentamente, então fiz um backup e tentei várias coisas descritas neste tópico: https://serverfault.com/questions/104417/how-do-i-easily-repair-a-single-unreadable-block-on-a-linux-disk

Como você pode ver no e-mail, isso foi há 1,5 anos, então não me lembro exatamente o que tentei e o que não. No entanto, o disco permanece estável e funcionando desde então, então não vejo motivo para mudar nada. (Sim, eu crio backups regularmente.)

Só consigo pensar em uma solução alternativa, que seria ignorar todos os e-mails que contenham esse texto exato, mas isso seria apenas tratar os sintomas, não a causa.

Editar:

Sei que muitos ou a maioria de vocês me darão o conselho de "substituir o disco", que em geral é o melhor conselho possível para uma pergunta como "Recebo este erro, o que devo fazer?"

Mas por favor,por favoraceito que estou ciente do risco e fazendo uma pergunta muito específica sobre o daemon SMART. Não encontrei nada nos documentos que indicasse que é possível fazer o que desejo, mas gostaria de verificar aqui antes de prosseguir com minha solução alternativa.

Atualizar:

Cerca de uma semana atrás, o contador caiu para 1 novamente. Não tenho ideia do que causou isso, não fiz nenhum trabalho de manutenção naquela máquina. Depois de mais de 2 anos, 11 setores ficaram bem novamente. Isso é muito estranho.

Responder1

você precisa alterar a configuração /etc/smartd.conf

adicione argumentos à sua configuração:

-t -I 197

Ignora o atributo 197 - Setores Pendentes

assim (exemplo):

/dev/ad0 -H -l error -l selftest -t -I 197

Responder2

A maneira mais simples de interromper a mensagem sem substituir o disco é forçar o disco a marcar os setores como bons ou ruins em vez de "talvez possivelmente ruim", que é o que significa "pendente". Você pode fazer isso forçando uma leitura completa do disco:

sudo dd if=/dev/sdb of=/dev/null bs=64K conv=noerror

Isso lerá todos os setores do disco e ignorará os erros, forçando o disco a verificar novamente cada setor pendente e informar se os setores estão realmente defeituosos ou não.

Observe que, embora isso limpe os atuais 11 setores pendentes, podedescubra novos setores potencialmente ruinsno processo (resultando em uma contagem de setores pendentes diferente de zero). Execute novamente até que não haja mais setores pendentes.

Responder3

Hmm... Não sei como você pode reconfigurar o smartd, mas agora que você pode fazer o OMD[1] ignorar certos erros SMART (uma vez fiz isso com uma contagem de setores realocados estabilizada). Talvez esta também seja uma opção para você se quiser monitorar mais parâmetros da sua caixa do que apenas as leituras SMART.

Responder4

Sabe-se que algumas unidades retornam esse erro incorretamente, como os SSDs da série Crucial MX500. Uma solução é configurar um arquivo db de unidade personalizado /etc/smart_drivedb.hcontendo o seguinte (tive que editar para corresponder ao meu número de firmware):

  { "Crucial/Micron MX500 SSDs",
    "CT(250|500|1000|2000)MX500SSD[14]", // tested with CT500MX500SSD1/M3CR023
    "M3CR032", // Firmware with bogus attribute 197
    "This firmware returns bogus raw values in attribute 197",
  //"-v 1,raw48,Raw_Read_Error_Rate "
    "-v 5,raw48,Reallocate_NAND_Blk_Cnt "
  //"-v 9,raw24(raw8),Power_On_Hours "
  //"-v 12,raw48,Power_Cycle_Count "
    "-v 171,raw48,Program_Fail_Count "
    "-v 172,raw48,Erase_Fail_Count "
    "-v 173,raw48,Ave_Block-Erase_Count "
    "-v 174,raw48,Unexpect_Power_Loss_Ct "
    "-v 180,raw48,Unused_Reserve_NAND_Blk "
    "-v 183,raw48,SATA_Interfac_Downshift "
    "-v 184,raw48,Error_Correction_Count "
  //"-v 187,raw48,Reported_Uncorrect "
  //"-v 194,tempminmax,Temperature_Celsius "
  //"-v 196,raw16(raw16),Reallocated_Event_Count "
    "-v 197,raw48,Bogus_Current_Pend_Sect " // Randomly flips 0 <> 1
  //"-v 198,raw48,Offline_Uncorrectable "
  //"-v 199,raw48,UDMA_CRC_Error_Count "
    "-v 202,raw48,Percent_Lifetime_Remain "
    "-v 206,raw48,Write_Error_Rate "
    "-v 210,raw48,Success_RAIN_Recov_Cnt "
    "-v 246,raw48,Total_LBAs_Written "
    "-v 247,raw48,Host_Program_Page_Count "
    "-v 248,raw48,FTL_Program_Page_Count"
  }

Depois de criar o arquivo, execute service smartd restartpara atualizar o serviço smartd. Então você poderá grep smartd /var/log/syslogver se ele está habilitado para a unidade.

Fonte:Tíquete de suporte do Smartmontools

informação relacionada