SMART-Test nunca termina

17

Al ejecutar SMART-Tests con smartmontools, NUNCA terminan. Siempre recibo "Interrupción (reinicio del host)" en varios sistemas y discos diferentes, incluidos Debian en x86 y ARM, OS X en x64, con unidades externas e internas. Incluso cuando se ejecuta en modo cautivo con discos todos vacíos (puestos a cero con dd).

¿Qué estoy haciendo mal?

hard-drive smart maintenance Max Ried
fuente
No estás haciendo nada malo contigo. Es el hardware que no funciona
Ramhound
¿Está destinado a funcionar en absoluto?
Max Ried
Sí, debería estar funcionando
Ramhound
@MaxRied, ¿está diciendo que ha intentado esto en muchas computadoras diferentes con registros de discos diferentes y que aún no ha visto una finalización, incluso para discos que sabe que son saludables gracias a una herramienta de análisis SMART diferente?
Frank Thomas
@FrankThomas Sí.
Max Ried

Respuestas:

14

Cuando la unidad no maneja ninguna actividad de entrada / salida durante la prueba, puede pasar al modo de espera, lo que aumenta la Interrupted (host reset)condición. Intente leer desde el disco a intervalos adecuados:

while true; do dd if=/dev/disk1 of=/dev/null count=1; sleep 60; done

(reemplácelo /dev/disk1con el dispositivo apropiado; lee un sector de ese dispositivo cada 60 segundos hasta que presione ctrl-c)

Esto ayudó en mi entorno: OS X 10.6.8, unidad WD Elements conectada a USB, SAT-SMART-driver 0.8.

Una prueba cautiva teóricamente debería mantener el disco en línea. Sin embargo, el comando de hardware enviado por smartctlpuede exceder el tiempo de espera antes de que se complete la prueba, lo que hace que el núcleo restablezca el enlace y termine en la misma situación que la anterior ( error # 303 ).

Consulte este hilo en la lista de correo de soporte de smartmontools para obtener más detalles. Reconozco a Christian Franke por la información dada aquí.

sve.g
fuente
Otras posibles interrupciones ( serverfault.com/a/584055 ): un cable defectuoso puede causar tiempos de espera y el núcleo activará un reinicio. Estoy menos seguro de que sea necesario dejar de smartd. Cualquier tiempo de espera e interrupciones aparecerán en dmesg / kern.log / journalctl -fk.
Tobu
Wow, eso es una locura! Confirmación: después de dejar caer un HGST HDN726060ALE610 desde un espejo zpool, se quedó atascado al 10% durante 36 horas (terminará más rápido sin otra actividad, ¿DERECHO?). Cinco minutos de estas pequeñas lecturas de dd hicieron que terminara. Escepticismo descartado.
Bill McGonigle
Se /dev/disk1supone que es el dispositivo o la partición, es decir, como /dev/sdao /dev/sda1?
Merchako
@ Merchako Esto está relacionado con Mac os donde en realidad es así.
Max Ried
5

Probé la solución de Tobu, en mi caso, seguí encontrando la unidad USB externa en modo de suspensión, independientemente de que en algún momento después de comenzar la prueba e interrumpirla, parece que dd terminó leyendo desde un caché del núcleo y el caché era lo suficientemente grande para el disco para ingresar al modo de suspensión. Noté que llamar a smartctl para preguntar por el estado siempre podía "despertar" el disco. Entonces: esta versión de la misma idea me funcionó:

sudo bash -c 'while true; do smartctl -a /dev/sdb > /dev/null; sleep 60; done'

Después de 5 horas, el disco USB externo sigue girando. Por primera vez pude ver una prueba de smartctl larga finalizada en un disco externo.

Creo que esta solución también tiene la ventaja de que las cabezas de los discos no se mueven innecesariamente cada minuto. El largo plazo terminó casi exactamente en el tiempo previsto (el script de mantenimiento no agregó tiempo a la ejecución)

Ari
fuente
3

Se debe usar una variación de la respuesta de Ari watch, porque la smartctlsalida puede ser interesante para hacer un seguimiento del estado:

sudo watch -d -n 60 smartctl -a /dev/sdx

Esto actualizará automáticamente la salida de smartctl -acada 60 segundos, para que pueda ver cuánto queda del tiempo de autocomprobación y resaltar los cambios (por lo que es más fácil detectar que la prueba realmente está progresando).

Gran esmeralda
fuente
+1, nunca watchantes visto .
Hashim
1

La prueba cautiva puede no funcionar si lleva más de 20 segundos.

Fuente: ticket # 303 , titulado "En modo cautivo de prueba inteligente, extienda el tiempo de espera como lo describe el dispositivo ATA".

Sergey V
fuente