Todos los servidores que corren Linux facilitan enormemente la tarea de detectar fallos en discos duros, proceder a su parada y sustituirlos por otros nuevos, integrándolos transparentemente en el RAID que solemos implementar en nuestros servidores.
¿Cómo se detecta que un disco es defectuoso? La primera pista nos la va a dar un cambio drástico en el servidor: bajada de rendimiento, problemas de acceso a ficheros, servicios caídos, etc. Es en ese momento cuando debemos pasar a comprobar la salud de los discos duros del sistema y descubrir cuál (o cuales) es el que tiene problemas.
La forma más directa y sencilla de comprobar si un disco duro está teniendo problemas es consultar el registro de los mensajes del núcleo con el comando dmesg. Ahí buscaremos referencias a errores de acceso a disco, problemas en las operaciones de lectura/escritura, menciones a relocalización de sectores, etc.
dmesg | less
...
ata2.00: failed command: READ FPDMA QUEUED
ata2.00: cmd 60/08:00:d8:5b:89/00:00:89:00:00/40 tag 0 ncq 4096 in
res 41/40:08:d8:5b:89/00:00:89:00:00/00 Emask 0x409 (media error)
ata2.00: status: { DRDY ERR }
ata2.00: error: { UNC }
sd 1:0:0:0: [sdb] Unhandled sense code
sd 1:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 1:0:0:0: [sdb] Sense Key : Medium Error [current] [descriptor]
sd 1:0:0:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
sd 1:0:0:0: [sdb] CDB: Read(10): 28 00 89 89 5b d8 00 00 08 00
end_request: I/O error, dev sdb, sector 2307480536
...
En el ejemplo vemos que el disco problemático es sdb. Igualmente sencillo es comprobar si se ha caído algún disco del RAID del servidor:
cat /proc/mdstat
Personalities : [raid1] md3 : active raid1 sda4[2] sdb4 1839220031 blocks super 1.2 [2/1] [U_]
De nuevo comprobamos que sdb es el culpable. Sin embargo, al tratarse de servidores, la forma más adecuada de detectar fallos en los discos es mediante la prevención a través de un sistema de monitorización al que incorporemos los controles necesarios, normalmente basados en la tecnología S.M.A.R.T. que se encuentra presente en los discos duros desde hace ya muchos años.
El soporte S.M.A.R.T. en Linux se consigue a través del paquete smartmontools, que permite controlar y monitorizar sistemas de almacenamiento utilizando dicha tecnología. De hecho, se incluye un demonio que nos avisa inmediatamente si se producen errores en alguno de los discos monitorizados.
Una vez identificado el disco defectuoso procedemos a comprobar su salud mediante smartctl, una herramienta de línea de comandos incluida en smartmontools. Con esta utilidad podremos no sólo obtener detallada información sobre el disco, sino además llevar a cabo completos tests que nos mostrarán si es defectuoso y cuál es el defecto concreto. Veamos unos ejemplos.
Para obtener información sobre un disco tenemos a nuestra disposición varios parámetros. Si queremos información sobre el hardware:
$ smartctl -i /dev/sdb
=== START OF INFORMATION SECTION ===
Device Model: ST…
Serial Number: W…
Firmware Version: C…
User Capacity: 3,000,592,982,016 bytes
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Fri Nov 22 12:33:54 2013 CET
SMART support is: Available – device has SMART capability.
SMART support is: Enabled
Podemos ampliar estos datos con la información SMART del disco duro con el parámetro `-a`. Si en cambio usamos `-x`, la salida del comando incluirá la información que no proviene de SMART.
$ smartctl -a /dev/sdb=== START OF INFORMATION SECTION ===
...
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
...
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 107 098 006 Pre-fail Always - 186855524
3 Spin_Up_Time 0x0003 093 093 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 8
5 Reallocated_Sector_Ct 0x0033 092 092 036 Pre-fail Always - 10640
7 Seek_Error_Rate 0x000f 083 060 030 Pre-fail Always - 219208774
...Si alguno de los anteriores comandos falla, podemos añadir el parámetro -T permissive (e incluso -T verypermissive) para intentar que smartctl ignore los errores que pueda y obtenga toda la información posible del disco.
Pasemos a lo realmente interesante: la realización de tests en los discos duros. La primera y más sencilla opción que tenemos a nuestra disposición es el parámetro -H, que nos informa de la salud SMART del disco.
smartctl -H /dev/sdb
=== START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED
Esta opción sólo indica que la salud es mala cuando el disco ya ha fallado o va a fallar en las próximas 24 horas. Podemos ver en el ejemplo que, a pesar de que sdb es defectuoso, se nos informa de que la salud SMART del disco es buena.
Para detectar el problema del disco en detalle contamos con el parámetro -t, que a su vez admite un argumento que indica el tipo de test a realizar: offline, short, long yconveyance. Todas estas pruebas se pueden realizar con el sistema en producción, a menos que usemos el parámetro -C, que las ejecuta en modo cautivo (no tiene efecto en tests de tipo offline). Este modo sirve para realizar las pruebas más rápidamente y tiene especial utilidad cuando la máxima prioridad es comprobar la salud del disco. La explicación en detalle de cada uno de estos tests se encuentra en el manual electrónico de smartctl.
Excepto en el mencionado modo cautivo, los tests se realizan en segundo plano, por lo que no obtenemos ninguna información por pantalla a menos que la pidamos explícitamente con el parámetro -l selftest. Dado que esto sólo nos muestra un instante del progreso del test, es interesante combinarlo con el comando watch, que por defecto realiza la tarea que le asignemos cada dos segundos. Veamos un ejemplo:
smartctl -t short /dev/sdb
=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === Sending command: "Execute SMART Short self-test routine immediately in off-line mode". Drive command "Execute SMART Short self-test routine immediately in off-line mode" successful. Testing has begun. Please wait 1 minutes for test to complete. Test will complete after ...
Use smartctl -X to abort test.
watch smartctl -l selftest /dev/sdb
Every 2,0s: smartctl -l selftest /dev/sdb === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error 1 Short offline Completed: read failure 90% 15073 2307480536
¡Eureka, hemos encontrado el defecto del disco sospechoso! Se trata de un error de lectura en al menos un sector del disco, siendo el primero detectado el especificado en la salida de smartctl. Ahora sólo queda cambiarlo por uno nuevo y llevar el defectuoso al fabricante a que nos lo cambie (si está en garantía, claro). Por cierto, en el ejemplo vemos cómo se nos informa de que podemos abortar cualquier test con smartctl -X.
Como curiosidad, si necesitamos conocer el modelo y número de serie del disco para el trámite con el fabricante, podemos obtenerlos con este sencillo comando (además de con smartctl -i):
hdparm -i /dev/sdb | grep SerialNo
Model=ST..., FwRev=C..., SerialNo=W...