El disco duro lee errores que ... ¿se detienen?

Mi historia comienza de manera bastante simple. Tengo un servidor liviano, que ejecuta Arch Linux, que almacena la mayoría de sus datos en un RAID-1 compuesto por dos unidades SATA. Funcionó sin problemas durante aproximadamente 4 meses. Luego, de repente, comencé a recibir errores de lectura en una de las unidades. Siempre, los mensajes se parecían mucho a estos:

Apr 18 00:20:15 hope kernel: [307085.582035] ata5.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Apr 18 00:20:15 hope kernel: [307085.582040] ata5.01: failed command: READ DMA EXT
Apr 18 00:20:15 hope kernel: [307085.582048] ata5.01: cmd 25/00:08:08:6a:34/00:00:27:00:00/f0 tag 0 dma 4096 in
Apr 18 00:20:15 hope kernel: [307085.582050]          res 51/40:00:0c:6a:34/40:00:27:00:00/f0 Emask 0x9 (media error)
Apr 18 00:20:15 hope kernel: [307085.582053] ata5.01: status: { DRDY ERR }
Apr 18 00:20:15 hope kernel: [307085.582056] ata5.01: error: { UNC }
Apr 18 00:20:15 hope kernel: [307085.621301] ata5.00: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640972] ata5.01: configured for UDMA/133
Apr 18 00:20:15 hope kernel: [307085.640986] sd 4:0:1:0: [sdd] Unhandled sense code
Apr 18 00:20:15 hope kernel: [307085.640989] sd 4:0:1:0: [sdd]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr 18 00:20:15 hope kernel: [307085.640993] sd 4:0:1:0: [sdd]  Sense Key : Medium Error [current] [descriptor]
Apr 18 00:20:15 hope kernel: [307085.640998] Descriptor sense data with sense descriptors (in hex):
Apr 18 00:20:15 hope kernel: [307085.641001]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
Apr 18 00:20:15 hope kernel: [307085.641010]         27 34 6a 0c 
Apr 18 00:20:15 hope kernel: [307085.641020] sd 4:0:1:0: [sdd]  Add. Sense: Unrecovered read error - auto reallocate failed
Apr 18 00:20:15 hope kernel: [307085.641023] sd 4:0:1:0: [sdd] CDB: Read(10): 28 00 27 34 6a 08 00 00 08 00
Apr 18 00:20:15 hope kernel: [307085.641027] end_request: I/O error, dev sdd, sector 657746444
Apr 18 00:20:15 hope kernel: [307085.641035] ata5: EH complete
Apr 18 00:20:15 hope kernel: [307085.641672] md/raid1:md16: read error corrected (8 sectors at 657744392 on sdd1)
Apr 18 00:20:17 hope kernel: [307087.505082] md/raid1:md16: redirecting sector 657742336 to other mirror: sdd1

Cada error se quejó de un número de sector diferente y estuvo acompañado de un retraso de varios segundos para que el usuario (yo) accediera al disco.

Verifiqué la salida de smartctl y vi la siguiente salida (partes irrelevantes recortadas):

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       0
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       51

Mirando hacia atrás en los registros, descubrí que los errores habían estado ocurriendo durante unos días, principalmente durante las copias de seguridad, pero también con frecuencia durante el uso muy ligero (es decir, cada 5 veces que intenté guardar un archivo de texto). Llegué a la conclusión de que mi disco se estaba muriendo, que el RAID-1 lo estaba manejando adecuadamente y que era hora de pedir un disco de reemplazo. Pedí un nuevo disco.

Para mi sorpresa, un día después, los errores ... se detuvieron. No había hecho nada para arreglarlos. No había reiniciado, no había desconectado el disco, nada. Pero los errores simplemente se detuvieron.

En ese momento, curioso por ver si los sectores defectuosos estaban ahora en porciones inactivas del disco, saqué el disco del RAID, lo volví a colocar en el RAID y le permití completar la resincronización completa subsiguiente. La resincronización se completó sin errores, 9 horas más tarde (los discos de 2 TB tardan un poco).

Además, la salida de smartctl ha cambiado un poco, de la siguiente manera:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   193   193   051    Pre-fail  Always       -       1606
  5 Reallocated_Sector_Ct   0x0033   194   194   140    Pre-fail  Always       -       43
196 Reallocated_Event_Count 0x0032   162   162   000    Old_age   Always       -       38
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0

Entonces, la parte de esto que me está extrañando es, por supuesto, "¿Desde cuándo se arreglan los discos malos?"

Supongo que es posible que un área muy pequeña de la unidad se estropeó espontáneamente, y que la unidad simplemente tomó 3 días (!) Antes de que su código de reasignación de sector se activara y mapeó algunos sectores de repuesto sobre un área defectuosa del disco ... Pero no puedo decir que haya visto que eso suceda.

¿Alguien más ha visto este tipo de comportamiento? Si es así, ¿cuál fue su experiencia con el viaje después? ¿Sucedió de nuevo? ¿El disco finalmente falló por completo? ¿O fue solo una falla inexplicable que permaneció sin explicación?

En mi caso, ya tengo la unidad de reemplazo (obtenida bajo garantía), por lo que probablemente solo la reemplace de todos modos. Pero me encantaría saber si lo diagnostiqué mal de alguna manera. Si ayuda, tengo una salida 'smartctl -a' completa de cuando estaba ocurriendo el problema. Es un poco largo, así que no lo publiqué aquí.

Si una región física específica de la superficie de la unidad falla, entonces hasta que esos sectores se puedan mapear con éxito, obtendrá errores de lectura no recuperados cuando intente leer los datos que se escribieron en esa área. La unidad sabe que los sectores son malos (después de fallar en el acceso a los sectores) pero no puede reasignar los sectores porque ya contienen datos. Si formatea la unidad o sobrescribe los sectores "defectuosos", la unidad tendrá la oportunidad de mapear los sectores defectuosos.

Una vez que se mapean los sectores defectuosos, y siempre que no falle la mayor parte de la superficie de la unidad, estará en buena forma.

No sé lo suficiente sobre los modelos de falla de unidad de las unidades actuales para saber si hay mucha correlación entre una parte de la superficie del medio que falla y el problema se propaga o vuelve a ocurrir. Si no hay correlación, una vez que los sectores defectuosos se mapean, está en buena forma. Si no es una correlación, entonces este es el principio del fin para la unidad.

La mayoría de las unidades modernas "vectorizarán" un bloque que se ha estropeado. La unidad tiene un conjunto de bloques de repuesto y el firmware los utiliza para reemplazar los bloques que la unidad considera defectuosos. La unidad no puede realizar esta reasignación cuando no puede LEER un bloque porque no puede suministrar los datos correctos. Simplemente devuelve "error de lectura". MARCA el bloque como malo, por lo que si el bloque se lee correctamente, el bloque se vectoriza y los datos correctos se escriben en el bloque de reemplazo. Si el sistema operativo ESCRIBE alguna vez en un bloque que está en un estado "pendiente de salida de vector", entonces el bloque se vectoriza y los datos se escriben en el bloque de reemplazo.

La incursión de software de Linux, al obtener un error de lectura de un dispositivo, obtendrá los datos correctos de otros elementos en la matriz y luego intenta ESCRIBIR el bloque defectuoso nuevamente. Entonces, si la escritura funciona bien, entonces los datos están seguros, de lo contrario, la unidad solo hace lo anterior, vectoriza el bloque y luego realiza la escritura. ¡Así que, la unidad, con la ayuda del sistema de incursiones, acaba de repararse sola!

Asumiendo que tales eventos son razonablemente raros, probablemente sea seguro continuar. Si se utilizan demasiados bloques de reemplazo, la unidad puede tener un problema. Existe un límite para la cantidad de bloques de reemplazo que se pueden vectorizar a bloques de repuesto y esa es una función del variador.

Sí, también he visto esto, y en circunstancias muy similares. En mi caso, fue una unidad "Verde" Western Digital de 1TB "de nivel de consumidor" (WD10EARS) lo que me atrajo. El Current_Pending_Sectorvalor bruto SMART pasó de cero a 6 y luego a 8, lo que provocó que el demonio de monitoreo SMART me enviara algunos correos electrónicos siniestros.

Me mdadm --failEd y --removeD del coche de la matriz y encontré un pase no destructiva de badblockssobre ella, y sí, había al parecer más de 2 docenas de bloques malos. Cuando la unidad de reemplazo llegó aproximadamente un día después, arreglé la matriz y la vida continuó.

Poco después, por puro aburrimiento, volví a conducir badblocksel disco "fallido" para ver si había empeorado. Por el contrario, la unidad se había "reparado" por completo: ¡cero bloques defectuosos! Sacudiendo mi cabeza, lo limpié y lo puse a un lado para ser reciclado o donado.

La lección: no use unidades de consumo en servidores, a menos que esté dispuesto y sea capaz de soportar todo tipo de rarezas y falta de fiabilidad. Corolario: no pierda el precio de los componentes del servidor, porque eventualmente terminará pagándolos de todos modos, en tiempo adicional y agravamiento.

Es una práctica común en entornos de servidor descartar unidades que alguna vez mostraron tales errores, reparados o no. Los errores duros del sector pueden ser un signo de daño físico en la superficie del medio, y si rasca una superficie, generalmente desplaza el material hacia los lados del rasguño y obtiene una rebaba más alta que el plano de dicha superficie, o polvo abrasivo (¡vidrio! ) Ambos tienden a ser bastante perjudiciales para un sistema mecánico que se basa en un colchón de aire muy delgado entre dos superficies que se supone perfectamente lisas ... es por eso que los errores medios una vez que comienzan a alcanzar un cierto recuento tienden a multiplicarse bastante más rápidamente.