El firmware de la unidad ejecuta las pruebas.
Los detalles de las pruebas se pueden leer, por ejemplo, en www.t13.org/Documents/UploadedDocuments/technical/e01137r0.pdf, que resume los elementos de las pruebas cortas y largas de la siguiente manera:
Un segmento eléctrico en el que el variador prueba su propia electrónica. Las pruebas particulares en este segmento son específicas del proveedor, pero como ejemplos: este segmento puede incluir pruebas tales como una prueba de RAM de búfer, una prueba de circuitos de lectura / escritura y / o una prueba de los elementos del cabezal de lectura / escritura.
un segmento de búsqueda / servo en el que la unidad prueba su capacidad para encontrar y servo en pistas de datos. La metodología particular utilizada en esta prueba también es específica del proveedor.
un segmento de exploración de lectura / verificación en el que la unidad realiza una exploración de lectura de alguna parte de la superficie del disco. La cantidad y la ubicación de la superficie escaneada dependen de la restricción de tiempo de finalización y son específicas del proveedor.
Los criterios para la autocomprobación extendida son los mismos que para la autocomprobación corta, con dos excepciones: el segmento (3) de la autocomprobación extendida debe ser un escaneo de lectura / verificación de toda el área de datos del usuario, y no hay límite de tiempo máximo para que la unidad realice la prueba.
Es seguro realizar pruebas no destructivas mientras se ejecuta el sistema operativo, aunque es probable que haya algún impacto en el rendimiento. Como smartctldice la página del manual para ambos -t shorty -t long,
Este comando se puede dar en la operación normal del sistema (a menos que se ejecute en modo cautivo)
Si invoca el modo cautivo con -C, se smartctlsupone que la unidad puede estar ocupada por falta de disponibilidad. Esto no debe hacerse en una unidad que el sistema operativo está utilizando.
Como la página del manual también sugiere, las pruebas fuera de línea (que simplemente significa pruebas periódicas de antecedentes) no son confiables y nunca se convirtieron oficialmente en parte de las especificaciones de ATA. Corro el mío desde cron, en su lugar; de esa manera sé cuándo deberían suceder, y puedo detenerlo si lo necesito.
- Los resultados se pueden ver en la
smartctlsalida. Aquí hay uno con una prueba en ejecución:
[root @ risby images] # smartctl -a / dev / sdb
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.6-201.fc22.x86_64] (compilación local)
Copyright (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
[...]
SMART Self-test estructura de registro número de revisión 1
Num Prueba_Descripción Estado Vida restante Tiempo (horas) LBA_de_primer_error
# 1 Extendido fuera de línea Completado sin error 00% 20567 -
# 2 Extendido fuera de línea Completado sin error 00% 486 -
SMART Selective self-test log estructura de datos número de revisión 0
Nota: el número de revisión no 1 implica que nunca se ha ejecutado una autocomprobación selectiva
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Self_test_in_progress [queda 90%] (0-65535)
2 0 0 No_prueba
3 0 0 No_prueba
4 0 0 No_prueba
5 0 0 No_prueba
Tenga en cuenta dos pruebas completadas anteriormente (a las 486 y 20567 horas de encendido, respectivamente) y la actual en ejecución (10% completado).
MadHatter apoya a Monica
fuente
Las implementaciones SMART dependen del fabricante, a veces hay registros bastante extensos disponibles a través del
smart -acomando. Esto es lo que obtengo en una de mis unidades de autocifrado de Hitachi :Este documento técnico arroja algo de luz sobre los códigos de error que aparecen en el registro. Las abreviaturas de error comunes son:
En mi caso, el error IDNF (ID no encontrado) puede rastrearse hasta un incidente cuando la unidad se conectó a través de un adaptador USB a SATA y resultó tener poca potencia, lo que impidió que buscara correctamente.
fuente