LLevo unos días usando lo que era básicamente un portátil de desguace como ordenador principal y ha sido básicamente gracias a que he podido suplir la falta de disco duro de éste mediante el uso de un stick USB de memoria. A pesar de que el tamaño del mismo o es gran cosa, 4GB que con formato y particiones se quedan en unos escasos 3.5GB, no echo en falta de nada ya que tengo una distribución Ubuntu 10.4 completa en unos 2.5GB perfectamente actualizada ya que he agregado algunos extras como Gimp (edición de imagen) o Audacity (edición de audio) de los que no me suelo separar así como los codecs habituales para ver las series y escuchar la música que llevo de aquí para allá.
Ya he tratado en otra ocasión cómo hacer una copia de seguridad y restaurar la misma llegado el caso. Gracias a esto pude tener dos sistemas de archivos en principio idénticos sobre los que realizar una batería de pruebas con motivo de optimizar al máximo el rendimiento sin tocar parámetros de hardware, una de mis premisas es que el sistema debe estar contenido en el stick USB y ser totalmente independiente del equipo donde se pinche para funcionar siempre y cuando éste soporte el arranque vía puerto USB y su arquitectura se corresponda con la Intel x86.
Dicho esto, y por dejarlo lo más claro posible, resumiré hasta su mínima expresión los pasos dados. Si aún estás interesado pero se te escapa algo te invito a usar los comentarios para preguntar cualquier duda.
Básicamente el conjunto se comporta como si en lugar de un disco duro físico estándar tuviera un disco SSD de memoria por lo que el acceso y la búsqueda de la información en el sistema de archivos es tremendamente rápido por lo que, por ejemplo, los tiempo de arranque y apagado del sistema son mucho menores, si bien la transferencia de grandes bloques de información se resiente y cuando tratamos archivos grandes podemos notar una ligera demora. Por esto utilizaremos un par de optimizaciones básicas y que aseguren la fiabilidad de los datos por encima de todo como caballo de batalla.
ATENCIÓN: fallar en la ejecución de algunos de los comandos que pondré más adelante puede dejar el equipo inutilizable, debéis estar realmente seguros de lo que hacéis…
1.- Montar tmpfs en RAM
Dicho así puede sonar raro pero si digo que tener el sistema de archivos temporal montado en memoria RAM reducirá notablemente el acceso al dispositivo alargando su vida útil y será aún más rápido gracias a unos tiempos de respuesta menores por todos los procedimientos que requieran de su uso seguro que suena mejor. Para ello editaremos el archivo “/etc/fstab” y añadiremos la siguiente línea:
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
Esto reducirá en algunos MB la memoria disponible pero merece la pena por el beneficio de rendimiento obtenido.
2.- Optimizar el sistema de archivos
Por defecto y desde el uso del sistema de archivos tipo “ext3”, las distribuciones de Linux asigna el atributo “relatime” al sistema de archivos lo que significa que, por diversos motivos que no vienen al caso, el timestamp de cualquier archivo es modificado y por tanto escrito de nuevo cada vez que un archivo es leído. En mi caso y en el del común de los mortales esto puede no ser de vital importancia y evitar un acceso de escritura al dispositivo de nuevo alargará la vida útil además de mejorar el rendimiento del mismo. Para hacer esto modificaremos el archivo “/etc/fstab” y agregaremos o sustituiremos el atributo existente “atime” ó “relatime” por “noatime”:
UUID=cf1a7636-ba1f-d62d32a14224 / ext4 noatime,errors=remount-ro 0 1
Podríamos ir mucho más lejos con métodos mucho más agresivos pero eso lo dejo a vuestra elección. Sólo diré que el atributo “data=writeback” obliga a escribir los metadatos en segundo plano y siempre que no se esté llevando a cabo un proceso con mayor prioridad o no sea necesario de su lectura por lo que en caso de fallo de alimentación o cuelgue general del sistema podríamos perder los últimos datos con los que estuviésemos trabajando aún creyendo que hemos guardado ese archivo. Para finalizar otro atributo interesante como “barrier=0” el cual no impone la escritura de los datos volátiles a disco resultando en un aumento del rendimiento considerable si el dispositivo soporta este método pero será seguro siempre y cuando que la escritura definitiva de los datos se haga tras la seguridad de una batería alternativa en caso de fallo de alimentación. La siguiente línea en “fstab” sería tan agresiva con el rendimiento como volátiles los datos en caso de que alguien tropezase con el cable de alimentación:
UUID=cf1a7636-ba1f-d62d32a14224 / ext4 noatime,data=writeback,barrier=0,errors=remount-ro 0 1
Sigo con mi batería de pruebas porque estoy obteniendo unos resultados más que satisfactorios, en torno a un 60% de mejora en tiempos de ejecuciñon y acceso al “disco”, en breves pondré algo por aquí…
