Cómo interpretar estos datos de smartctl (smartmon)

Tenemos un servidor Linux que ha estado en uso intensivo durante 3 años. Estamos ejecutando una serie de servidores virtualizados en él, algunos que no se han comportado bien, y durante un tiempo significativo se superó la capacidad de io del servidor, lo que provocó una mala espera. Tiene 4 unidades Barracuda sata de 500 gb conectadas a un controlador RAID 3com. 1 Drive tiene el sistema operativo, y los otros 3 están configurados raid-5.

Ahora tenemos un debate sobre la condición de las unidades y si están fallando activamente.

Aquí hay una parte de la salida para 1 de los 4 discos. Todos tienen estadísticas relativamente similares:

Número de revisión de la estructura de datos de atributos SMART: 10
Atributos SMART específicos del proveedor con umbrales:
ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 118 099 006 Pre-error siempre - 169074425
  3 Spin_Up_Time 0x0003 095 092 000 Pre-fallo siempre - 0
  4 Start_Stop_Count 0x0032 100 100 020 Old_age Siempre - 26
  5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
  7 Seek_Error_Rate 0x000f 077 060 030 Pre-error siempre - 200009354607
  9 Power_On_Hours 0x0032 069 069 000 Old_age Siempre - 27856
 10 Spin_Retry_Count 0x0013 100100 097 Pre-fail Always - 1
 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Siempre - 26
184 Atributo_desconocido 0x0032 100100 099 Old_age Siempre - 0
187 Reportado_ Incorrecto 0x0032 100 100 000 Old_age Siempre - 0
188 Atributo_desconocido 0x0032 100 100 000 Old_age Siempre - 1
189 High_Fly_Writes 0x003a 100100 000 Old_age Siempre - 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 Siempre - 29 (0 21 0 0)
195 Hardware_ECC_Recovered 0x001a 046 033 000 Old_age Always - 169074425
197 Current_Pending_Sector 0x0012 100100 000 Old_age Siempre - 0
198 Offline_Irecorrectable 0x0010 100100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 200200 000 Old_age Siempre - 0

Versión de registro de errores SMART: 1
No se registraron errores

Mi interpretación de esto es que no hemos tenido sectores defectuosos u otras indicaciones de que alguna de las unidades está fallando activamente.

Sin embargo, el alto Raw_Read_Error_Rate y Seek_Error_Rate se señala como indicaciones de que las unidades están muriendo.

En mi experiencia, Seagates tiene números extraños para esos dos atributos SMART. Cuando diagnostico un Seagate, tiendo a ignorarlos y mirar más de cerca otros campos como Recuento de sectores reasignados. Por supuesto, en caso de duda, reemplace la unidad, pero incluso los nuevos Seagates tendrán números altos para esos atributos.

Para los discos Seagate (y posiblemente también algunos antiguos de WD), Seek_Error_Rate y Raw_Read_Error_Rate son números de 48 bits, donde los 16 bits más significativos son un recuento de errores, y los 32 bits más bajos son varias operaciones.

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

Entonces su disco ha realizado 2440858991 búsquedas, de las cuales 46 fallaron. Mi experiencia con las unidades Seagate es que tienden a fallar cuando el número de errores supera los 1000. YMMV.

La "tasa de error de búsqueda" y la "tasa de error de lectura sin formato" RAW_VALUES no tienen prácticamente ningún significado para nadie más que el soporte de Seagate. Como otros señalaron, los valores brutos de parámetros como "recuento de sector reasignado" o entradas en el registro de errores de la unidad tienen más probabilidades de indicar una mayor probabilidad de falla.

Pero puede echar un vistazo a los datos interpretados en las columnas VALUE, WORST y THRESH que deben leerse como indicadores:

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

Lo que significa que su tasa de error de búsqueda se considera actualmente "77% buena" y SMART informa que es un problema cuando alcanza "30% buena". Había sido tan bajo como "60% bueno" una vez, pero se ha recuperado mágicamente desde entonces. Tenga en cuenta que los valores interpretados se calculan mediante la lógica SMART de la unidad internamente y el fabricante puede publicar o no el cálculo exacto y, por lo general, el usuario no puede modificarlo.

Personalmente, considero que una unidad que contiene entradas de registro de errores está "fallando" y solicito un reemplazo tan pronto como ocurra. Pero en general, los datos SMART han resultado ser un indicador bastante débil para la predicción de fallas, como descubrió un artículo de investigación publicado por Google .

Me di cuenta de que esta discusión es un poco vieja, pero quiero agregar mis 2 centavos. He encontrado que la información inteligente es un buen indicador de pre-falla. Cuando se dispara un umbral inteligente, reemplace la unidad. Para eso están esos umbrales.

La gran mayoría de las veces comenzará a ver sectores defectuosos. Esa es una señal segura de que la unidad está comenzando a fallar. SMART me ha salvado muchas veces. Uso el software RAID 1 y es muy útil, ya que simplemente reemplazas la unidad que falla y reconstruyes la matriz.

También realizo autoevaluaciones cortas y largas semanalmente.

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

O agréguelo /etc/smartd.conf y envíelo por correo electrónico si hay errores

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

Asegúrese de instalar logwatch y redirigir la raíz a una dirección de correo electrónico y verificar los correos electrónicos diarios de logwatch. Las banderas disparadas de SMARTD aparecerán allí, pero no sirve de nada si nadie está monitoreando eso regularmente.

Sí, esos campos se ven mal, pero no confío (ya) en la información informada por smart (mi máquina de prueba tiene una unidad que debería estar muerta hace mucho tiempo si lee los datos con smartctrl) El hecho es que ha informado alto iowait y las unidades tienen 3 años. Esto debería ser suficiente para que pueda cambiar las unidades.

Lamento cometer necromancia en esta publicación, pero en mi experiencia, los campos "Tasa de errores de lectura sin procesar" y "Recuperación de ECC de hardware" para una unidad Seagate literalmente irán por todas partes e incrementarán constantemente en el rango de billones en ese punto. Volveré a cero para continuar el proceso nuevamente. Tengo un Seagate ST9750420AS que ha tenido ese problema desde el primer día y aún funciona muy bien incluso después de varios años y más de 3500 horas de uso.

Creo que esos campos pueden ignorarse con seguridad si está ejecutando uno en su caso. Solo asegúrese de que los dos campos reporten el mismo número y estén sincronizados constantemente. Si no lo son ... bueno ... Eso podría significar un problema.

Para automatizar los cálculos de esta respuesta , use la calculadora javascript en línea:

https://yksi.ml/

Esto te dirá:

• Numero total de operaciones
• Número de operaciones fallidas

La calculadora es válida para Seagate:

• Tasa de error de búsqueda
• Tasa de errores en la lectura
• Hardware ECC recuperado

Para obtener más información sobre el cálculo de los valores normalizados (entre 0 y 100), consulte este artículo .