Cómo interpretar resultados SMART y Badblocks

2

He comprado un SSHD usado (Seagate Laptop SSHD - ST500LM000-1EJ162) en eBay. Con respecto a SMART, el disco podría estar dañado de alguna manera, no estoy seguro. Para interpretar correctamente los valores SMART, necesito su ayuda.

Con respecto a SMART, tengo una gran cantidad de errores de lectura sin procesar y errores de búsqueda. He leído muchos hilos diferentes sobre este tema hasta ahora y lo que he descubierto es que estos dos valores mencionados son casi irrelevantes, porque no hay una estandarización sobre qué tipo de error debe ocurrir para permitir que estos dos valores (Raw- Los errores de lectura y error de búsqueda) aumentan. Es el fabricante quien decide sobre esto: en términos generales: Seagate tiende a tener valores RAW altos de errores de lectura y búsqueda sin procesar, mientras que Western Digital tiende a tener valores RAW bajos en este segmento. He leído, debido a este hecho, sería inútil tratar de interpretar los valores RAW de estos dos atributos, en su lugar, debería comparar las columnas llamadas VALOR con PEOR y UMBRAL. Y aquí entra el siguiente problema. Ahora es lo contrario: se prefiere un VALOR más alto que UMBRAL.

Para aclarar las cosas, eche un vistazo al smartctl -a /dev/sdb/fragmento a continuación.

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 120 099 006 Pre-error siempre - 237676480

Con respecto a SMART, tengo un Raw_Read_Error_Rate con un valor RAW de 237676480. Esto parece peligroso en primer lugar. Pero con respecto a las columnas VALUE WORST THRESH, tengo un VALOR (?) Real de 120. El PEOR caso una vez fue 099 y si cae por debajo de THRESH 006, el disco debe considerarse roto.

Lo mismo ocurre con el sector reasignado. Cuanto más bajos sean los valores de la columna en comparación con el valor THRESH, peor será la condición del disco.

Entonces, con respecto a mi fragmento SMART a continuación, mi disco nunca reasignó nada.

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
  5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0

Ahora echemos un vistazo a Reported-Uncorrected-Error's . Según tengo entendido, estos errores son contados, siempre que el disco no puede reasignar un sector defectuoso con el resultado de que los datos almacenados dentro de dicho sector se pierden.

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
187 Reportado_ Incorrecto 0x0032 099 099 000 Old_age Siempre - 1

Con respecto al fragmento SMART anterior, el disco tenía un sector sin corregir en su vida útil. Con respecto a las columnas VALOR y PEOR, no hay que tener miedo de ningún fallo de disco.

Otro atributo es Airflow-Temperature-Cel . Primero instalé el disco en mi computadora portátil de 12 años y corrí badblocksa revisar mi disco. Mientras badblocksestaba funcionando durante varias horas, verifiqué el valor de temperatura INTELIGENTE y vi que el valor de la columna era igual a PEOR y ambos cayeron por debajo de UMBRAL. Como RAW_VALUE tenía una declaración como: DISK IS FAILING. Así que decidí apagar mi computadora portátil e instalar ese SSHD en mi servidor doméstico que tiene un mejor flujo de aire y se reinició badblocks. Entonces, al verificar este atributo INTELIGENTE ahora, la columna PEOR describe el caso, que ocurrió el día anterior en mi computadora portátil, mientras que la columna VALOR muestra la temperatura real. Comparando VALOR con THRESH la temperatura está bien. Intentar interpretar el valor RAW_VALUE es algo con lo que tengo problemas. Aquí el fragmento

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
190 Air_Temperature_Cel 0x0022 068 037 045 Old_age Siempre In_the_past 32 (0 120 37 26 0

Por último, pero no menos importante, hay información SMART que nunca he leído en ninguna salida SMART durante mi vida, y no tengo ni idea de cómo interpretarlas:

Se produjo el error 4 durante la vida útil del disco: 521 horas (21 días + 17 horas)
  Cuando se produjo el comando que causó el error, el dispositivo estaba activo o inactivo.

  Después de que se completó el comando, los registros fueron:
  ER ST SC SN CL CH DH
  - - - - - - -
  04 71 03 80 04 11 40

  Los comandos que condujeron al comando que causó el error fueron:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command / Feature_Name
  - - - - - - - - ---------------- ------------------ -
  ea 00 00 00 00 00 00 00 00: 13: 30.508 FLUSH CACHE EXT
  61 00 08 00 09 9c 40 00 00: 13: 30.507 ESCRIBE FPDMA QUEUED
  61 00 08 78 e1 42 40 00 00: 13: 30.507 ESCRIBIR FPDMA QUEUED
  61 00 28 f0 44 9d 40 00 00: 13: 30.507 ESCRIBE FPDMA QUEUED
  61 00 08 00 6f 71 47 00 00: 13: 29.805 ESCRIBIR FPDMA QUEUED

Se produjo el error 3 durante la vida útil del disco: 519 horas (21 días + 15 horas)
  Cuando se produjo el comando que causó el error, el dispositivo estaba activo o inactivo.

  Después de que se completó el comando, los registros fueron:
  ER ST SC SN CL CH DH
  - - - - - - -
  04 51 00 a0 25 e7 06

  Los comandos que condujeron al comando que causó el error fueron:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command / Feature_Name
  - - - - - - - - ---------------- ------------------ -
  ea 00 00 00 00 00 00 00 00: 11: 47.000 FLUSH CACHE EXT
  61 00 08 88 c4 a0 40 00 00: 11: 45.863 ESCRIBIR FPDMA QUEUED
  60 00 08 40 d4 08 49 00 00: 11: 45.863 LEER FPDMA QUEUED
  61 00 08 00 09 9c 40 00 00: 11: 45.863 ESCRIBIR FPDMA QUEUED
  60 00 12 19 47 5a 40 00 00: 11: 45.863 LEER FPDMA QUEUED

Se produjo el error 2 durante la vida útil del disco: 519 horas (21 días + 15 horas)
  Cuando se produjo el comando que causó el error, el dispositivo estaba activo o inactivo.

  Después de que se completó el comando, los registros fueron:
  ER ST SC SN CL CH DH
  - - - - - - -
  40 51 00 40 d4 08 09 Error: WP en LBA = 0x0908d440 = 151573568

  Los comandos que condujeron al comando que causó el error fueron:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command / Feature_Name
  - - - - - - - - ---------------- ------------------ -
  61 00 08 78 e1 42 40 00 00: 10: 28.019 ESCRIBE FPDMA QUEUED
  61 00 08 e0 96 a0 40 00 00: 10: 27.914 ESCRIBIR FPDMA QUEUED
  61 00 08 98 95 a0 40 00 00: 10: 27.914 ESCRIBIR FPDMA QUEUED
  61 00 08 70 95 a0 40 00 00: 10: 27.914 ESCRIBIR FPDMA QUEUED
  61 00 08 58 95 a0 40 00 00: 10: 27.914 ESCRIBIR FPDMA QUEUED

Se produjo el error 1 durante la vida útil del disco: 426 horas (17 días + 18 horas)
  Cuando se produjo el comando que causó el error, el dispositivo estaba activo o inactivo.

  Después de que se completó el comando, los registros fueron:
  ER ST SC SN CL CH DH
  - - - - - - -
  04 71 03 80 04 11 40

  Los comandos que condujeron al comando que causó el error fueron:
  CR FR SC SN CL CH DH DC Powered_Up_Time Command / Feature_Name
  - - - - - - - - ---------------- ------------------ -
  ea 00 00 00 00 00 00 00 00: 35: 26.857 FLUSH CACHE EXT
  61 00 08 00 09 9c 40 00 00: 35: 26.856 ESCRIBIR FPDMA QUEUED
  61 00 08 ff ff ff 4f 00 00: 35: 26.161 ESCRIBIR FPDMA QUEUED
  61 00 08 ff ff ff 4f 00 00: 35: 26.161 ESCRIBIR FPDMA QUEUED
  61 00 08 ff ff ff 4f 00 00: 35: 26.160 ESCRIBIR FPDMA EN COLA

De las publicaciones que he leído en diferentes foros, las personas tienden a aconsejar reemplazar los discos antes de que las cosas empeoren. También he leído cómo algunas personas comentan que han podido usar tales discos durante varios años antes de morir hasta morir. Para mí, esta es una tierra nueva. Nunca tuve un disco con tantos errores. Probablemente el propietario antes manejó mal ese disco. Por ejemplo, agitar mucho su computadora portátil, o los conectores SATA no se adaptaron perfectamente, lo que causó errores también. Como dije, no tengo idea de cómo interpretar estos parámetros. Es como un experimento que voy a hacer con este disco.

Verifiqué el disco badblocks -wvs -b 4096 -o badblox.result /dev/sdby no tuve errores. ¡¡NO COPIE Y PEGUE EL MANDO DE BLOQUES !!! . Pero al comparar los resultados de smartctl -a /dev/sdbantes y después de ejecutar, badblocksel número de Raw_Read_Error_Rate y Seek_Error_Rate aumentó mucho, mientras que todos los demás valores de atributos permanecieron iguales. Verifique el fragmento a continuación:

Antes de ejecutar badblocks.

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 104099006 Pre-falla siempre - 6995776
  7 Seek_Error_Rate 0x000f 059 055 030 Pre-error siempre - 107395771838

Después de babdblockshaber terminado.

ID # ATTRIBUTE_NAME VALOR DE LA BANDERA PEOR TIPO DE UMBRAL ACTUALIZADO CUANDO_FALLO RAW_VALUE
  1 Raw_Read_Error_Rate 0x000f 120 099 006 Pre-error siempre - 237676480
  7 Seek_Error_Rate 0x000f 059 055 030 Pre-error siempre - 107395783395

Toda la salida SMART se puede revisar en PasteBin:

Entonces mis preguntas son:

  • ¿Cuánto daño grave tiene este disco?
  • ¿Es correcta mi interpretación sobre Raw-Read y Seek-Error?
  • ¿Tener cero sectores reasignados es algo bueno?
  • ¿Tener solo un error no reasignado no es tan malo?
  • ¿Cero errores al ejecutar badblockssignifica que el disco está en buen estado?
  • ¿Cómo debo interpretar el error 1 al error 4 ?
  • ¿Alguna prueba más que deba hacer, aparte de la prueba automática smartctl -t long /dev/sdbque se está ejecutando en realidad?
AlexOnLinux
fuente

Respuestas:

3

Muy rápidamente:

  • Los valores brutos no significan nada. Pueden variar de un firmware a otro, y a menos que sepa exactamente lo que significa su valor bruto para su hardware específico, no intente interpretarlos. A veces es obvio (temperatura en grados centígrados), a menudo no lo es.

  • Los valores están normados a 100, menor es peor. Si es 100 o superior, no hay que preocuparse. Si está por debajo de 100, el disco duro muestra un poco de desgaste. Si se acerca al umbral, o debajo de él, comience a preocuparse.

  • Todos los discos duros tienen errores de lectura sin formato. Esa es una consecuencia de la alta densidad de las unidades actuales, y para eso está la corrección de errores incorporada.

  • Entonces: su tasa de lectura sin procesar se ve bien. Su tasa de sector reasignada es excelente, lo que significa que todavía no ha sucedido nada grave. Algunos sectores reasignados no son motivo de preocupación.

  • Su temperatura es demasiado alta por alguna razón, verifique que el disco duro esté refrigerado adecuadamente. La tasa de error de búsqueda es demasiado alta, esto puede ser una consecuencia de que la temperatura sea demasiado alta, lo que hace que el metal se expanda un poco, lo que puede mover la posición del cabezal fuera de las especificaciones.

Entonces, de lo que debe preocuparse es del enfriamiento adecuado. Si puede hacer que eso funcione, los errores de búsqueda deberían disminuir, y en su lugar me quedaría con el disco duro. (Pero, por supuesto, estás haciendo copias de seguridad, ¿no?)

Editar

El error 1-4 proviene de un registro de los cinco errores más recientes que se comunicaron en la capa ATA. Por lo general, obtienes un encabezado como

SMART Error Log Version: 1
ATA Error Count: xxx (device log contains only the most recent five errors)
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]

Por lo tanto, se pueden buscar valores de comandos y características en el estándar ATA para obtener más detalles sobre lo que sucedió. Pero tener errores de vez en cuando no es nada de qué preocuparse: el controlador integrado es complejo, la interacción con el host es compleja, el tiempo es complejo; Si ocurren algunas circunstancias extrañas, esa es una forma de obtener un error. Otras formas son los errores en el firmware del controlador incorporado que solo se activan en estas circunstancias extrañas.

Solo cuando los errores ocurren con frecuencia, en este momento, y continúan ocurriendo, es hora de preocuparse, especialmente si siempre es el mismo error.

Tiene tres errores que ocurrieron después de un vaciado de caché, y uno después de una escritura (LBA = dirección de bloque lógico). Dos ocurrieron juntos, probablemente como consecuencia del mismo problema, y ​​el anterior y el posterior ocurrieron independientemente debido a eso. En su lugar, los ignoraría por completo: lo que sea que los haya causado ha terminado y no volverá a suceder.

dirkt
fuente
Hola, gracias por tu rápida respuesta. Es bueno saber que mi interpretación no fue tan mala en absoluto. ¿También podría darme una respuesta sobre cómo entender el Error1 al Error 4 ?
AlexOnLinux