Problemas con un disco duro Western Digital

Por Fernando Acero

Tras la muerte súbita de mi anterior ordenador, me compré un equipo bastante apañadito y a un precio razonable. Entre el hardware estaba un disco duro SATA de Western Digital, modelo ‎WDC WD5000AADS-0 de 500 Gb, de la serie Caviar Green, que además de ser silencioso, no se calentaba mucho, a pesar de sus 32 Mb de caché y su velocidad de transferencia de 3 Gb/s. Está entre medias de las series Caviar Black de alto rendimiento y la Caviar Blue de andar por casa. Tras unos meses y 499 horas de funcionamiento impecable, el disco ha comenzado a dar problemas...

Aunque la información que proporciona SMART es que el disco está perfectamente, el caso es que de vez en cuando se enciende la luz del disco y el sistema se queda completamente bloqueado durante un tiempo variable, que ronda los dos minutos en este momento y que se ha ido incrementando poco a poco desde unos 20 segundos iniciales. Al parecer, este problema se produce cuando se intenta grabar en el disco archivos de cierto tamaño (superior a 1 Mb).

Por ejemplo, la forma más sencilla de provocar el problema es arrancar el ordenador y bajar el correo diario, en cuanto hay un mensaje con un tamaño superior a 1 Mb aproximadamente, se enciende la luz de actividad del disco, se para la descarga y toca esperar dos minutos, más o menos, a que todo vuelva a la normalidad. El caso es que no soy el único que tiene este problema con este disco, ni es un problema que se produzca solamente a los usuarios de Linux, por lo que tiene toda la pinta de ser algo intrínseco al disco duro:

a) Usuario de Windows 7.
b) Usuario de una HD box de Thomson.
c) Usuario de Arch x86_64..

Pero basta con buscar en Google, para encontrar más usuarios que tienen este mismo problema con este modelo de disco duro.

Lo primero que hice, fue usar el paquete SMART TOOLS, para comprobar el estado del disco mediante un completo test de la unidad. El resultado fue correcto. Después, usé el mandato iotop de Linux para ver si había alguna aplicación que estuviera haciendo un uso intensivo del disco, pero para mi sorpresa, no había ninguna aplicación que estuviera haciendo un uso tan intensivo del disco, como para que el sistema quedase congelado durante dos minutos cada cierto tiempo. La conclusión era que el disco tenía un problema cuando escribía desde el caché, que por cierto, es de gran tamaño (32 Mb). Visto lo visto, he devuelto el disco a la tienda donde lo adquirí para ver lo que me dicen y sigo esperando a que me digan algo. Antes cloné el contenido de ese disco, instalando un Seagate ST3500418AS de 500 Gb, lo supuso una hora y media de espera, usando el milagroso mandato:

dd if=/dev/sda of=/dev/sdb bs=1M

También borré el disco usando una herramienta de borrado seguro, lo volví a formatear y finalmente, eliminé todas las particiones con la herramienta de particionado que viene con Mandriva. Hasta llegar a la conclusión de que era un problema del disco, he hecho de todo, cambiar los puertos, reformateos, reinstalaciones, etc. Daba igual si el disco estaba como primario, o como secundario, en cuanto se escribía algo que tuviera aproximadamente 1 Mb de tamaño, el sistema se quedaba congelado y cada vez tardaba más tiempo en descongelarse. Otro dato, tras copiar bit a bit el contenido del Western Digital en el Seagate, este último no mostraba ningún problema, lo que asegura que el fallo no se debía a una mala configuración del software, o de la BIOS. Por cierto, el disco ni el disco de Seagate ni el Western Digital, aparecen en la base de datos de SMART TOOLS, por lo que veré la forma colaborar con el proyecto para solucionar esa carencia.

Con independencia de lo anterior, e investigando sobre los posibles problemas de este disco, recordé la polémica surgida, allá por el 2007, en torno al agresivo sistema de aparcado de cabezas que usaban los discos de Western Digital y tras revisar algunas cosas, me temo que sigue vigente en la actualidad. Aunque me sorprende la poca información que hay sobre el tema.

De hecho, este disco, a sus 499 horas de funcionamiento y tras usar el mandato smartctl -a /dev/sda, ya mostraba en el parámetro SMART 193 Load_Cycle_Count un nada despreciable valor de 48.771, lo que implica que las cabezas de esta unidad se han aparcado una media de 98 veces cada hora. También es cierto, que SMART sigue dando al contador de este parámetro el valor /183, que es su valor máximo, lo que implica que SMART TOOLS no considera que tan elevado número de ciclos de aparcamiento de los cabezales sea un problema por el momento.

Sin embargo, el fabricante cifra en unos 300.000, los ciclos de carga/descarga en su documentación técnica, lo que implicaría, que de seguir a este ritmo, a este disco le quedarían unas 3.118 horas de funcionamiento, que es muy poco, si lo comparamos con las increíbles 15.495 horas que ya llevan los dos discos duros Seagate Barracuda de 7.200 rpm y 40 Gb, de mi anterior ordenador y que todavía están plenamente operativos en este nuevo ordenador, como unidades de respaldo.

Idéntico problema lo tiene el disco duro de mi ordenador portátil Packard Bell, que a sus 966 horas de funcionamiento, ya muestra un Load_Cycle_Count de 64.347, o lo que es lo mismo, una media de 67 aparcamientos de cabeza por cada hora de funcionamiento, lo que también es un valor muy alto. Por lo que a la vista de estos valores y los datos que proporciona el fabricante en su documentación técnica, la situación es más que preocupante si quiero que los discos me duren algo más de 1 año. Haciendo una simple estimación, las cabezas de mis dos discos duros WD se aparcan cada 10 segundos, más o menos, por lo que es necesario reducir de forma considerable este ratio, si quiero que mis discos duren un tiempo razonable.

Pero hay que tener en cuenta dos cosas, si se aumenta el tiempo entre los aparcamientos de las cabezas:

a) El disco consumirá más, lo que es un problema para un portátil.
b) El disco estará menos protegido ante un golpe en funcionamiento al estar las cabezas sin aparcar, lo que es un problema para un portátil.

Teniendo en cuenta estas cosas, me puse a buscar. El fabricante proporciona un procedimiento para regular este comportamiento de ahorro de energía para los usuarios de MAC y de Windows, pero no hay nada para los usuarios de Linux. Allá en el año 2007, Western Digital, lanzó un programa, para ejecutar desde el MS-DOS, que permite desactivar la gestión de energía, pero tengo la duda de que funcione con este disco duro tan moderno y temo que incluso pudiera dañarlo. En todo caso, para usarlo desde Linux, no habría más remedio que recurrir a una imagen de FreeDOS, que habría que modificarla mediante ISO Master, para introducir el programa wdidle3.exe en el directorio raíz y luego grabarla como CD de arranque. La sintaxis de WWIDLE3 es:

WDIDLE3 Version 1.00
Copyright (C) 2005-2008 Western Digital Corp.
Configure Idle3.
Using DT32.LIB version 09A

Syntax:
WDIDLE3 [/S[]] [/D] [/R] [/?]
where:
/S[] Set timer, units in 100 milliseconds (1 to 255). Default=80.
/D Disable timer.
/R Report current timer.
/? This help info.

Si somos usuarios de Linux, lo primero que tenemos que probar es el mandato hdparm (nota: el dispositivo debe ser el adecuado a nuestro sistema, en mi caso es /dev/sda, pero depende de la configuración y del tipo de disco duro que estemos usando, lo que debemos tener en cuenta para el resto de los mandatos de este artículo), por ejemplo con mi serial ATA como master, yo he usado el mandato:

hdparm -B 255 /dev/sda

Este mandato, desactiva la gestión de energía de nuestro disco duro y por lo tanto, impide que se aparquen las cabezas. Lo que está bien, cuando el ordenador está alimentado a través de la red eléctrica (por ejemplo, un ordenador de sobremesa o un portátil conectado a la red eléctrica) y en un sitio estable, sin riesgos de golpes y vibraciones.

Valores intermedios, permitirán controlar el tiempo entre aparcamientos de las cabezas, lo que será más adecuado cuando el ordenador es un portátil y está alimentado por baterías. El parámetro -B de hdparm permite configurar las capacidades avanzadas de gestión de energía del disco, si es que el disco soporta esta característica. Un valor bajo, implica una gestión de energía más agresiva y un valor elevado, implica unas mejores prestaciones, con un mayor consumo y un mayor riesgo en caso de golpes o vibraciones. Los valores entre 1 y 127 permiten "spin down" y los valores entre 128 y 254 no lo permiten. El valor de 255 desactiva el sistema avanzado de gestión de energía, pero hay que saber que aunque hay discos que aunque soportan la variación del valor del parámetro -B, no permiten desactivar la gestión avanzada de energía. También hay que señalar, que este mandato se ha de utilizar siempre que se arranque el sistema ya que el disco no lo recuerda de un arranque para otro.

Desgraciadamente, este mandato que funciona perfectamente con el disco duro de mi portátil, cuando intento usarlo con el disco duro del ordenador de sobremesa, me aparece lo siguiente:

hdparm -B 255 /dev/sda
/dev/sda:
setting Advanced Power Management level to disabled
HDIO_DRIVE_CMD failed: Input/output error
APM_level = not supported

Es decir, que no funciona. La realidad es que este disco duro no acepta ningún valor para el parámetro -B. A la vista de este problema, alguien propuso en cierto momento, con toda su buena intención, usar un script algo "salvaje" para reducir, o evitar, las entradas el disco en modo de ahorro de energía y con ello, los excesivos aparcamientos de las cabezas:

#!/bin/bash
while /bin/true
do
/bin/sleep 6
echo a > /tmp/a
/bin/sync;/bin/sync;/bin/sync
done

Aunque el script funciona, yo le veo varios problemas muy graves:

a) Escribe siempre en la misma posición del disco cada 6 segundos, lo que puede acabar dañando el disco. Dicho de otro modo, el remedio puede ser peor que la enfermedad.
b) Entorpece de forma sensible el funcionamiento de los algoritmos de optimización del disco.
c) El mandato sync ya no está disponible en muchas distribuciones Linux, en su lugar, hay que usar hdparm -F /dev/sda.

Por lo tanto, en su lugar, yo propongo instalar el paquete SMART TOOLS y usar este otro script, que es mucho menos agresivo que el anterior:

#!/bin/bash
while /bin/true
do
/bin/sleep 7
smartctl -a /dev/sda
done

A diferencia del anterior, este script no escribe en el disco y en teoría, tampoco mueve las cabezas, puesto que solamente accede a la memoria cada 7 segundos para consultar la base de datos SMART, lo que impide que el disco entre en el modo de bajo consumo y aparque las cabezas, sin poner en riesgo su integridad física o afectando
negativamente a los algoritmos de optimización de las lecturas o escrituras.

La temporización del script se puede ajustar a gusto del consumidor, modificando el valor 7 por otro que se considere más adecuado, recordando que por defecto las cabezas se aparcarán cada 8 o 10 segundos, así que si ponemos 11, lo que provocaremos con casi toda probabilidad, es un aumento considerable en los ciclos de aparcamiento y desaparcamiento, que es lo que queremos evitar.

Veamos ahora la forma en la que un escript puede ejecutarse en el arranque del ordenador, lo que nos puede servir para el mandato hdparm -B XXX /dev/xxx, o para el script propuesto anteriormente, dependiendo de lo que acepte nuestro disco duro.

1) Lo primero que tenemos que saber, es el runlevel en el que se ejecuta nuestro ordenador, para ello, ejecutaremos el mandato runlevel desde una consola con los permisos de root. En mi caso, que uso Mandriva, el runlevel de ejecución gráfica es el N 5.

2) Luego, crearemos el archivo con el script o el mandato en el directorio /etc/init.d, por ejemplo usando vi disco_flush y una vez creado, le daremos permisos de ejecución con le mandato chmod u+x /etc/init.d/disco_flush.

3) Seguidamente, para que se ejecute en el runlevel 5, iremos al directorio /etc/rc5.d y crearemos un enlace simbólico al script que hemos dejado en /etc/init.d, pero teniendo en cuenta lo que digo a continuación. Como veremos al usar el mandato ls, en ese directorio hay otros enlaces simbólicos a otros tantos scripts. Todos empiezan por S y un número de dos cifras. Hay que buscar un número alto, para que el script se ejecute al final de todos, pero que no esté usado. En mi caso el 96 está libre, por lo que usaré el mandato ln -s /etc/init.d/disco_flush S96disco_flush.

4) Ahora si volvemos a arrancar el sistema, abrimos una consola y usamos el mandato ps aux | grep disco_flush, nos saldrá algo parecido a esto si hemos optado por el script, puesto que si optamos por el mandato, solamente se ejecutaría una vez al arrancar y no se quedaría en modo "demonio":

root 3557 0.0 0.0 3864 1256 ? S 14:02 0:00 sh -c /etc/rc5.d//S96disco_flush start 2>&1
root 3558 0.0 0.0 3872 1264 ? S 14:02 0:00 /bin/bash /etc/rc5.d//S96disco_flush start

Lo anterior nos indica que el script está funcionando en modo demonio y con ello, evitando todo el tiempo que esté encendido nuestro ordenador, que el disco entre en modo de ahorro de energía y que con ello, aparque las cabezas.

Si cada cierto tiempo usamos el mandato smartctl -a /dev/sda desde una consola de root, comprobaremos que el número asociado al parámetro Load_Cycle_Count, no aumenta, o que se ha reducido la velocidad con la que aumenta y de paso, hemos mejorado algo las prestaciones del disco duro.

Espero que esto sea de utilidad y logre salvar algún que otro disco duro de una muerte prematura. He de decir, que este procedimiento es el que estoy usando yo actualmente, aunque no doy ninguna garantía, ni me hago responsable, de posibles daños que se pudieran producir en el disco duro.

"Copyleft 2010 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"