Me encuentro en Kriptópolis y en Barrapunto lo que parece el notición geek del año:
Pues qué malo que es el Ubuntu ese, ¿no? Pues a mí no me lo parece, la verdad. A mí me parece que los fabricantes de discos duros nos están vendiendo productos artificialmente poco duraderos. Vayamos por partes.
Resulta que hay una tecnología de fabricación de discos duros llamada de Load/Unload (Un Whitepaper muy aconsejable en PDF sobre el tema: Ramp : Ramp Load/Unload Technology in Hard Disk Driver, encontrado en Broken HDDs) cada vez más extendida, sobre todo en discos duros de portátil. Consiste en que el cabezal de lectura/escritura, en vez de estar permanentemente volando sobre el disco, se aparca frecuentemente, lo que teóricamente permite una mayor duración del disco, menor consumo y mayor protección contra golpes.
Sin embargo, no se puede aparcar la cabeza un número indefinido de veces, sino que estos discos están preparados para un número máximo de ciclos de carga/descarga del cabezal que según el disco en cuestión puede ser de orden de 300K o 600K ciclos (K=1000). No es que justo cuando se llegue a ese número el disco va a dejar de funcionar de repente, sino que a partir de ahí el fabricante ya considera que puede dejar de hacerlo en cualquier momento. Paul nos cuenta que en varios de sus discos ha llegado a 600K, 900K y 1200K ciclos de carga/descarga antes de que empezaran a dar problemas. Pero eso sólo ¡en un año!
Yo me interesé por el problema nada más leer sobre él porque el disco de 2.5″ de marca Western Digital que tengo conectado a la EPIA EX10000EG (apareció de pasada en la entrada Sobre las VIA EPIA (V) ) hacía clicks muy frecuentemente. Lo notaba mucho porque cuando el disco se quedaba idle durante unos segundos, al volver al trabajajo casi siempre hacía un click que me disgustaba mucho pero que pensaba que sería normal (es un disco nuevo y tras varios tests no había encontrado ningún error). Ahora sé que cada vez que se oye uno de esos clicks lo más normal es que sea el cabezal en un ciclo de carga/descarga.
Pues bien, resulta que consultando los parámetros S.M.A.R.T. del disco con el comando smartctl, me encuentro con que el disco ya ha usado 7755 ciclos:
# smartctl -a /dev/hdc | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 7755
Y no penséis que esta máquina se tira encendida semanas y semanas, ¡no!. Para llegar a ese número de ciclos, ese disco sólo ha pasado por una instalación de Debian y por todas las pruebas que le hice a la EX10000EG, incluyendo varios ratos de reproducción de vídeo. Por tanto, que haya consumido ya 7755 ciclos, que podría ser alrededor del 3% de los que el fabricante permite antes de que el disco sea declarado como “envejecido”, es una auténtica barbaridad.
En unas pruebas rápidas he podido ver que el número de ciclos crece muy rápidamente en pocos minutos y sin apenas usar la máquina:
Sun Oct 28 02:11:51 CEST 2007
193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 7744
Sun Oct 28 02:15:51 CEST 2007
193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 7753
Sun Oct 28 02:16:28 CEST 2007
193 Load_Cycle_Count 0x0032 198 198 000 Old_age Always - 7754
Como se comenta en los enlaces que hablan del problema, con el comando “hdparm -B” podemos modificar el nivel de gestión de energía que ha de tener el disco (usando APM):
# man hdparm
[...]
-B Set Advanced Power Management feature, if the drive supports it. A low value means
aggressive power management and a high value means better performance. A value of 255
will disable apm on the drive.
[...]
Podemos reducirlo al máximo:
# hdparm -B 254 /dev/hdc
/dev/hdc:
setting Advanced Power Management level to 0xFE (254)
O incluso deshabilitarlo:
# hdparm -B 255 /dev/hdc
/dev/hdc:
setting Advanced Power Management level to disabled
El caso es que tras hacer lo último, el valor de Load_Cycle_Count en la salida del smartctl ya no crece más que en una unidad cuando arranco, así que me lo he puesto en el fichero /etc/rc.local, para que se ejecute siempre durante el arranque. Los clicks también han desaparecido, así que todo es mucho mejor ahora.
Y es que en este sistema, aunque le puse un disco de 2.5″ para que no consumiera mucho porque la fuente es tan sólo de 60W, tampoco necesito que sea muy estricto en materia de ahorro de energía como si se tratara, por ejemplo, de un portátil trabajando con baterías, y prefiero evitar un envejecimiento prematuro del disco.
El problema con Ubuntu, el que ha creado toda esta alarma, es que en modo laptop, que no está habilitado por defecto, el fichero /etc/acpi/power.sh configura el disco para que ahorre energía de la forma más agresiva posible, con -B 1, haciendo que el disco tenga muchos más ciclos de carga y descarga y muchos más clicks:
function laptop_mode_enable {
...
$HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null
$HDPARM -B 1 /dev/$drive 2>/dev/null
}
En un bug report del problema que ya tiene bastantes meses, alguien ha probado con distintos valores de -B:
-B 128 -> 23 cycles in 10 minutes
-B 160 -> 29 in 10'
-B 180 -> 0 in 10'
-B 196 -> 0 in 10'
-B 200 -> 0 in 10'
Se ha generado alarma por Ubuntu e incluso en algunas otras distribuciones pero, en realidad, hay firmwares y BIOS que ya activan modos APM agresivos durante el arranque, como leemos en Problem with hard drive clicking, y como me ha pasado a mí mismo, que estaba sufriendo el problema con una Debian que no toca absolutamente nada de los parámetros del disco.
¿Y el problema no pasa en Windows? Pues yo no tengo ningún disco que haga clicks y que tenga Windows para probar si tras un rato de funcionamiento el valor de Load_Cycle_Count crece, pero yo esperaría que sí, ya que Windows suele optimizar bastante bien el consumo de energía en portátiles (los fabricantes de los mismos en realidad lo prueban todo en Windows).
Sí que puede ocurrir que en Linux los ciclos de carga y descarga ocurran mucho más a menudo, porque en Linux el kernel y los procesos se dedican a escribir muy frecuentemente en disco, siendo los periodos en los que el disco está idle mínimos. Cualquiera que haya intentado que un disco duro se quede parado tras un periodo de inactividad del sistema en Linux, se habrá dado cuenta de que no es una tarea fácil:
Pero para mí, me parece que lo más importante a recalcar es que en raíz, esto no es un problema de ningún sistema operativo, ni de ninguna distribución: ni Ubuntu, ni Debian, ni Fedora, ni Windows. No perdamos de vista que esto es un problema generado artificialmente por los fabricantes de discos duros que hacen su hardware con absurdas limitaciones.
Y, por cierto, no olvidemos que este es un problema sólo de los discos que se fabrican con esta tecnología de load/unload, a los que también podríamos llamar click-powered hard disks. En otros discos, dicho contador ni se estrena:
# smartctl -a /dev/sdb | egrep 'ID|Load_Cycle'
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
193 Load_Cycle_Count 0x0032 253 253 000 Old_age Always - 0
Una curiosidad para acabar: ¿Sabías que con la opción -M del hdparm puedes configurar tu disco para que intente hacer menos ruido?
:wq
Actualización 1/1/08: En A vueltas con el “hdparm -B” en Debian Lenny vuelvo a tratar el tema, enfocándolo esta vez a ver cómo están tratando el problema los desarrolladores de Debian en Lenny.
Actualización 2/5/08: Hace tiempo que está en los comentarios, pero creo que es importante recalcar que en lugar de añadir el comando “hdparm -B 254” al fichero /etc/rc.local, es mejor editar el fichero /etc/hdparm.conf y poner algo así (cambiando el fichero de dispositivo y el valor de apm según nuestras necesidades):
/dev/sda {
apm = 254
}
Seguido por el comando:
update-rc.d hdparm defaults
para que el hdparm se ejecute durante el arranque.
Actualización 5/5/08: Parece que en Ubuntu Hardy Heron no hay /etc/init.d/hdparm, de modo que probablemente siga siendo buena idea usar el /etc/rc.local.
