Como interpretar esses dados smartctl (smartmon)

Temos um servidor linux que está em uso pesado há 3 anos. Estamos executando vários servidores virtualizados, alguns que não foram bem comportados e, por um tempo significativo, a capacidade io do servidor foi excedida, resultando em problemas de iowait. Possui 4 unidades Barracuda sata de 500GB conectadas a um controlador de ataque da 3com. 1 O drive possui o sistema operacional e os outros 3 estão configurados como RAID-5.

Agora temos um debate sobre a condição das unidades e se elas estão falhando ativamente.

Aqui está uma parte da saída para 1 dos 4 discos. Todos eles têm estatísticas relativamente semelhantes:

Número de revisão da estrutura de dados dos atributos SMART: 10
Atributos SMART específicos do fornecedor com limites:
ID # ATTRIBUTE_NAME VALUE O MAIOR VALOR DE TIPO DE TERRA ATUALIZADO WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 118 099 006 Pré-falha Sempre - 169074425
  3 Spin_Up_Time 0x0003 095 092 000 Pré-falha Sempre - 0
  4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 26
  5 Reallocated_Sector_Ct 0x0033 100 100 036 Pré-falha Sempre - 0
  7 Seek_Error_Rate 0x000f 077 060 030 Pré-falha Sempre - 200009354607
  9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 27856
 10 Spin_Retry_Count 0x0013 100 100 097 Pré-falha Sempre - 1
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 26
184 Atributo desconhecido 0x0032 100 100 099 Old_age Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
188 Unknown_Attribute 0x0032 100 100 000 Old_age Always - 1
189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 071 060 045 Old_age Always - 29 (Lifetime Min / Max 26/37)
194 Temperature_Celsius 0x0022 029 040 000 Old_age Always - 29 (0 21 0 0)
195 Hardware_ECC_Recuperado 0x001a 046 033 000 Old_age Always - 169074425
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0
198 Off-line_Incorrigível 0x0010 100 100 000 Old_age Off-line - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0

Versão do log de erros SMART: 1
Nenhum erro registrado

Minha interpretação disso é que não tivemos setores defeituosos ou outras indicações de que alguma das unidades esteja falhando ativamente.

No entanto, os altos Raw_Read_Error_Rate e Seek_Error_Rate estão sendo apontados como indicações de que as unidades estão morrendo.

Na minha experiência, Seagates tem números estranhos para esses dois atributos SMART. Ao diagnosticar uma Seagate, costumo ignorá-las e examinar mais de perto outros campos como Reallocated Sector Count. É claro que, em caso de dúvida, substitua a unidade, mas mesmo os novos Seagates terão números altos para esses atributos.

Para discos da Seagate (e possivelmente também alguns antigos da WD), o Seek_Error_Rate e Raw_Read_Error_Rate são números de 48 bits, onde os 16 bits mais significativos são uma contagem de erros e os baixos 32 bits são um número de operações.

% python
>>> 200009354607 & 0xFFFFFFFF
2440858991
>>> (200009354607 & 0xFFFF00000000) >> 32
46

Portanto, seu disco realizou 2440858991 buscas, das quais 46 falharam. Minha experiência com as unidades da Seagate é que elas tendem a falhar quando o número de erros ultrapassa 1000. YMMV.

As "taxas de erro de busca" e "taxa de erro de leitura bruta" RAW_VALUES são praticamente sem sentido para ninguém, exceto o suporte da Seagate. Como outros salientaram, valores brutos de parâmetros como "contagem de setor realocado" ou entradas no log de erros do inversor têm maior probabilidade de indicar uma maior probabilidade de falha.

Mas você pode dar uma olhada nos dados interpretados nas colunas VALUE, WORST e THRESH, que devem ser lidos como medidores:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH
  7 Seek_Error_Rate         0x000f   077   060   030

Isso significa que sua taxa de erro de busca atualmente é considerada "77% boa" e é relatada como um problema pela SMART quando atinge "30% boa". Tinha sido tão baixo quanto "60% bom" uma vez, mas se recuperou magicamente desde então. Observe que os valores interpretados são calculados internamente pela lógica SMART do inversor e o cálculo exato pode ou não ser publicado pelo fabricante e normalmente não pode ser ajustado pelo usuário.

Pessoalmente, considero uma unidade que contém entradas de log de erros como "com falha" e solicito uma substituição assim que elas ocorrerem. Mas, em suma, os dados SMART acabaram sendo um indicador bastante fraco para a previsão de falhas, como descobriu um trabalho de pesquisa publicado pelo Google .

Percebi que essa discussão é um pouco antiga, mas quero adicionar meus 2 centavos. Eu achei as informações inteligentes um bom indicador de pré-falha. Quando você ativar um limite inteligente, substitua a unidade. É para isso que servem esses limites.

Na grande maioria das vezes você começará a ver setores defeituosos. Esse é um sinal claro de que a unidade está começando a falhar. O SMART me salvou muitas vezes. Eu uso o software RAID 1 e é muito útil, pois você simplesmente substitui a unidade com falha e reconstrói a matriz.

Também executo semanalmente o autoteste curto e longo.

smartctl -t short /dev/sda
smartctl -t long /dev/sda 

Ou adicione /etc/smartd.conf e envie-o por e-mail se houver erros

/dev/sda -s L/../../3/22 -I 194 -m someemail@somedomain
/dev/sdb -s L/../../7/22 -I 194 -m someemail@somedomain

Certifique-se de instalar o logwatch, redirecionar a raiz para um endereço de email e verificar os emails diários do logwatch. As bandeiras de disparo SMARTD aparecerão lá, mas não ajuda em nada que ninguém esteja monitorando regularmente.

Sim, esses campos parecem ruins, mas eu não confio (mais) nas informações relatadas pelo smart (minha máquina de teste tem uma unidade que deveria estar morta há muito tempo, se você ler os dados com o smartctrl) O fato é que você relatou iowait alto e as unidades têm 3 anos de idade. Isso deve ser suficiente para você mudar as unidades.

Lamento comprometer a necromancia nesta postagem, mas, na minha experiência, os campos "Taxa de erro de leitura bruta" e "ECC recuperado por hardware" para uma unidade Seagate literalmente vão por todo o lado e aumentam constantemente para a faixa de trilhões em que ponto retornará a zero para continuar o processo novamente. Eu tenho um Seagate ST9750420AS que tem esse problema desde o primeiro dia e ainda funciona muito bem, mesmo depois de alguns anos e mais de 3500 horas de uso.

Acho que esses campos podem ser ignorados com segurança se você estiver executando um no seu caso. Apenas verifique se os dois campos estão relatando o mesmo número e em sincronia constantemente. Se eles não estão ... bem ... Isso realmente pode significar um problema.

Para automatizar os cálculos desta resposta , use a calculadora javascript on-line:

https://yksi.ml/

Isto dirá a você:

• Número total de operações
• Número de operações com falha

A calculadora é válida para a Seagate:

• Taxa de erro de busca
• Taxa de erro de leitura bruta
• ECC de hardware recuperado

Para mais informações sobre o cálculo dos valores normalizados (entre 0 e 100), consulte este artigo .