Temos um servidor linux que está em uso pesado há 3 anos. Estamos executando uma série de servidores virtualizados, alguns que não foram bem comportados e, por um tempo significativo, a capacidade de io do servidor foi excedida, levando a um mau iowait. Tem 4 drives Barracuda sata de 500GB conectados a um controlador RAID da 3Com. 1 Drive possui o sistema operacional e os outros 3 são setup raid-5.
Agora, temos um debate sobre a condição das unidades e se elas estão fracassando ativamente.
Aqui está uma parte da saída de 1 dos 4 discos. Todos eles têm estatísticas relativamente semelhantes:
SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-fail Always - 169074425 3 Spin_Up_Time 0x0003 095 092 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 26 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 077 060 030 Pre-fail Always - 200009354607 9 Power_On_Hours 0x0032 069 069 000 Old_age Always - 27856 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 1 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 26 184 Unknown_Attribute 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_Recovered 0x001a 046 033 000 Old_age Always - 169074425 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 SMART Error Log Version: 1 No Errors Logged
A minha interpretação disto é que nós não tivemos quaisquer setores defeituosos ou outras indicações de que qualquer um dos drives está falhando ativamente.
No entanto, a alta Raw_Read_Error_Rate e Seek_Error_Rate estão sendo apontadas 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, tenho a tendência de ignorá-las e examinar mais de perto outros campos, como Reallocated Sector Count. É claro que, quando em dúvida, substitua a unidade, mas mesmo novos Seagates terão números altos para esses atributos.
Para discos da Seagate (e possivelmente alguns discos antigos da WD também) 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
Assim, o seu disco realizou 2440858991 pesquisas, das quais 46 falharam. Minha experiência com os discos da Seagate é que eles tendem a falhar quando o número de erros ultrapassa 1000. YMMV.
A "taxa de erro de busca" e a "taxa de erro de leitura bruta" RAW_VALUES são praticamente sem sentido para ninguém além do suporte da Seagate. Como outros salientaram, valores brutos de parâmetros como "contagem de setor realocado" ou entradas no log de erros do disco são mais propensos a indicar uma probabilidade maior de falha.
Mas você pode dar uma olhada nos dados interpretados nas colunas VALUE, WORST e THRESH, que devem ser lidos como indicadores:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH
7 Seek_Error_Rate 0x000f 077 060 030
Significa que sua taxa de erro de busca é atualmente considerada "77% boa" e é reportada como um problema pela SMART quando atinge "30% de bom". Tinha sido tão baixo quanto "60% bom" uma vez, mas magicamente se recuperou 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 contendo entradas do log de erros como "com falha" e desejo de uma substituição assim que elas ocorrerem. Mas, no geral, os dados da SMART revelaram-se um indicador bastante fraco para a previsão de falhas, como um artigo de pesquisa publicado pelo Google descoberto.
Eu percebi que essa discussão é um pouco antiga, mas quero adicionar meus 2 centavos. Eu encontrei a informação inteligente para ser um bom indicador de pré-falha. Quando você obter um limiar inteligente desarmado, substitua a unidade. Isso é o que esses limites são para.
Na maior parte do tempo, você começará a ver setores defeituosos. Esse é um sinal claro de que a unidade está começando a falhar. A SMART me salvou muitas vezes. Eu uso o software RAID 1 e é muito útil, pois você simplesmente substitui a unidade com falha e recria a matriz.
Eu também faço auto-teste curto e longo semanalmente.
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 e redirecionar a raiz para um endereço de e-mail e verificar os e-mails diários do logwatch. Sinalizadores tripulados do SMARTD aparecerão lá, mas não é de nenhuma ajuda se ninguém estiver monitorando isso 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 deve estar morta há muito tempo se você ler os dados com o smartctrl) O fato é que você relatou alto iowait e as unidades têm 3 anos de idade. Isso deve ser suficiente para você mudar as unidades.