A principios de 2012 le compré un nuevo disco duro a mi portátil con el único propósito de ampliar el escaso espacio libre que me quedaba en el antiguo. Por cierto, utilicé Clonezilla para la operación de copiar todas la información desde el disco original al nuevo y, mientras que mi sistema Linux salió andando sin problemas, tuve que dedicar varias horas a reparar la licencia de Windows Vista que aún conservo (ya que la pagué con el portátil, me la quedé).

Aunque el tener el doble de espacio es una gozada (pasé de 250 a 500GB), surgió un problema que no me esperaba: el rendimiento del portátil cayó notablemente, lo que en principio era achacable al acceso al nuevo disco. Así que para comprobar la validez de dicha sospecha, esta misma semana he realizado una serie de pruebas al nuevo disco desde Linux. Todas estas pruebas tuve que realizarlas como administrador del sistema ya que de otra forma no tendría los privilegios suficientes para acceder a los recursos necesarios para llevarlas a cabo de manera correcta.

Lo primero que hice fue comprobar el rendimiento del disco a nivel de hardware con el comando hdparm, una herramienta muy completa que permite realizar una gestión completa de nuestros discos duros. Como tal, es igualmente útil como peligrosa para nuestros datos si no la usamos bien.

En el caso que nos ocupa, utilicé dos parámetros simultáneamente para medir el rendimiento del nuevo disco. t nos devuelve la transferencia de datos directa (buffered) y T nos ofrece la transferencia de datos a través de caché (cached). Al combinar ambos parámetros en el mismo comando, se ponderan entre sí y nos ofrecen unos resultados más acordes con la realidad de nuestro dispositivo. Estos fueron mis resultados:

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   2234 MB in  2.00 seconds = 1094.17 MB/sec
 Timing buffered disk reads: 220 MB in  3.00 seconds =  71.56 MB/sec

Este comando hay que repetirlo tres veces para estar seguros de que los datos son estables y, por lo tanto, fiables. Comparando el resultado de las lecturas directas a disco con las especificaciones del fabricante (que hay que recordar que se obtienen en laboratorio en condiciones ideales y que por lo tanto hay que ponderar a la hora de hacer comparaciones con valores obtenidos en situaciones reales), descubrí que las primeras con aproximadamente un 50% de las segundas, lo que concuerda con lo que suele ser habitual. De hecho, hice pruebas con el disco antiguo y tuve resultados similares. Probé también con mi nuevo PC de sobremesa y más de lo mismo. Así que tocaba descartar problemas en el hardware.

El siguiente paso era comprobar el comportamiento de la E/S del disco bajo ciertas cargas, lo cual se puede simular con la herramienta fio. Mientras que hdparm suele venir de serie en cualquier distribución Linux, no es así el caso de fio, que se instala en Debian tan sencillo como así:

# apt-get install fio

El mejor escenario para comprobar el rendimiento de un disco es cuando se producen numerosos accesos aleatorios. Para ello, generé un fichero de simulación como el siguiente, en el que se transfieren 256 MB de datos:

# cat test.fio 
[random-read]
rw=randread
size=256m
directory=/tmp/test

A continuación, creé el directorio de pruebas:

# mkdir /tmp/test

e invoqué fio de la siguiente manera:

# fio test.fio

Esto genera gran cantidad de información, pero lo suficientemente clara como para darme cuenta de que el problema no estaba en la E/S del nuevo disco duro.

El último sospechoso era el sistema de ficheros. Estando seguro de que no tenía ningún fallo estructural (de eso se encarga el propio sistema de ficheros, ext3 en mi caso), pasé a comprobar el rendimiento del sistema de ficheros con la herramienta bonnie++, que nos ofrece completos (y complejos) informes con resultados.

Al igual que fio, bonnie++ no viene de serie en Linux, así que en Debian lo instalamos así:

# apt-get install bonnie++

Para utilizar bonnie++, necesitamos indicarle un directorio en el que pueda escribir sin problemas para poder hacer sus pruebas, así que como quería probar la partición en la que reside el sistema operativo, aproveché el directorio creado anteriormente en /tmp para ello.

# bonnie++ -u root -d /tmp/test

Al igual que con fio, con bonnie++ se obtiene gran cantidad de datos, que de nuevo fueron negativos a la hora de encontrar el culpable del bajo rendimiento del portátil. Tendré que buscar en otro sitio (¿poca RAM? ¿las exigencias de KDE? ¿un nuevo kernel?).

PD: Por cierto, para saber cómo se llama nuestro disco duro y nuestros sistemas de ficheros en nuestra instalación de Linux, basta con invocar el comando df -h.