Introducción
Se probaron distintos sistemas de archivos como block device en RAM, el propósito fue para encontrar el sistema de archivos más veloz en la memoria RAM.
Como antecedente está el sistema de archivos RAMFS usado para crear unidades de ramdisk , sin embargo RAMFS tiene el inconveniente de no poder controlar el espacio por lo que actualmente fue desplazado en los sistemas GNU/Linux por TMPFS.
Recursos y materiales usados:
Estas son las caracteristicas del equipo usado:
En Gentoo Linux se utilizó el software llamado phoronix-test-suite 6.2.1 como herramienta de benchmarking, las pruebas pueden ser reproducida sencillamente a travez de los comandos proporcionados y comparadas gracias a que la aplicación así lo dispone y que la información de las pruebas fue subida al internet.
Apesar de que frecuentemente se afirma que Gentoo es la distribución más rápida esto es meramente coincidencia y cualquier mejora sería despreciable.
Loop device vs block device desde el mismo kernel
En esta prueba inicial se busca determinar si usar un ramdisk como block device o como loop device es mejor, en esta prueba se consiguió un rendimiento practicamente igual, por lo que un método u otro puede usarse sin problemas.
Paso 1. Montar un block device desde la RAM
Se recompiló el kernel de Linux para soportar unidades virtuales de RAM por defecto por lo que la unidad /dev/ram0 quedó disponible al cargar el módulo brd con el siguiente comando:
modprobe brd rd_size=10485760
Seguido se formateó /dev/ram0 a ext2 y finalmente se realizó el benchmarking correspondiente:
Paso 2. Montar un loop device desde TMPFS
Se creó un archivo de 10GB en la memoria RAM con el siguiente comando:
dd if=/dev/zero of=/tmp/im.img bs=32768 seek=305175 count=0
Se le aplicó formato de ext2 con
mkfs.ext2 /tmp/im.img
Se añadió como loop device
losetup -f /tmp/im.img
Finalmente se montó en la ruta del entorno de pruebas
En el siguiente link se puede ver la comparasión
http://openbenchmarking.org/result/1608097-GA-MERGE856751
Observaciones:
El rendimiento no se inclina ni a favor de uno ni del otro pues en un 50% de las veces tanto uno como otro tuvo un mejor rendimiento en las mismas pruebas, resultado esperado en cuanto que comprueba que produce el mismo rendimiento usar un block device del kernel (/dev/ram0) o un loop device desde /tmp con TMPFS
Finalmente la diferencias en la velocidad de escritura son relativamente minimas a comparasión con los otros sistemas de archivos.
Pruebas de rendimiento entre los distintos sistemas de archivos
Estas pruebas son la parte escencial de esta investigación, donde se compararon los sistemas de archivos EXT4, EXT2, F2FS, XFS y JFS principalmente.
FS-Mark
Esta gráfica es una muestra de los resultados de esta prueba llamada FS-Mark, donde free-fs-mark es nuestro control de la prueba -ya que es un sistema de archivos TMFPS– y test2 es el sistema XFS.
Ext2-fs obtuvo el mejor rendimiento en todas las pruebas y adicionalmente obtuvo un mejor rendimiento en las pruebas con No Sync, seguido el segundo mejor rendimiento lo obtuvo el sistema de archivos F2FS (TOSHIBA MQ01ABD1), y el tercer mejor rendimiento fue de JFS. Vale la pena mencionar que EXT2 era el formato por defecto que se asignaba a los RAMFS antes
http://openbenchmarking.org/result/1606256-GA-MERGE294086
AIO Stress
AIO Stress es la prueba más básica que se puede hacer de I/O y en la siguiente gráfica se pueden apreciar los resultados:
En escritura aleatorea ext2 resultó ser el más rápido, luego ext4, y en tercer lugar F2FS
http://openbenchmarking.org/result/1606256-GA-MERGE320617
Dbench
Es una simulación de un servidor CIFS o NFS donde se simula (sin usar la red) los clientes y aplicaciones que puede tener al mismo tiempo antes de que empieze a haber lag , solo se enfoca en el sistema de archivos.
En estas pruebas se repiten 3 veces TOSHIBA MQ01ABD1 donde el de la primer posición es el sistema de archivos JFS, el de la segunda es EXT2 , y el de la tercera posición es F2FS y finalmente test3 corresponde a XFS.
Esta gráfica es una muestra de los resultados. No es sino hasta con 12 hilos que en general los sistemas de archivos obtienen su máximo rendimiento incluyendo nuestro sistema de control (free-dbench).
A partir de estos resultados se concluye que EXT2 es el sistema de archivos con el mejor rendimiento para este tipo de operaciones, seguido de F2FS, y luego ocurre una variación; JFS es el tercero más rápido para 1, 6 y 12 hilos, empero empieza a estar en desventaja a partir de 48 hilos donde ext4 logra superarlo.
http://openbenchmarking.org/result/1606251-GA-MERGE272074
IO Zone
Io Zone permite hacer un benchmark del rendimiento de un sistema de archivos con archivos de distintos tamaños.
http://openbenchmarking.org/result/1606267-GA-MERGE129407
EXT4 y EXT2 se mantuvieron en un rango similar, sin embargo EXT2 se mostró superior a final de cuentas. De forma general EXT2 fue el mejor. Para archivos grandes XFS fue el mejor, sin embargo JFS destacó demasiado así que lo dejo como el segundo mejor de esta prueba.
Optimizaciones intentadas:
Se probó cambiar el scheduler a deadline para JFS sin obtener realmente mejora.
También los dos parametros de la cache de los discos fueron fijados a cero y afectó el rendimiento de todas las pruebas tanto en block device del kernel como en loop device montado como archivo.
Raids 0:
Tratando de superar el cuello de botella que tienen los sistemas de archivos XIP trate de crear un raid de software creando distintas particiones en la memoria RAM, supuestamente el cuello de botella en un sistema de archivos ext2 sería debido a que necesita mayor escritura en el primer superbloque.
Se creo un raid 0 de 6 particiones virtuales donde los archivos más grandes perdieron en rendimiento mientras que los archivos más pequeños la diferencia era minima a no haber montado el raid.
Conclusiones:
EXT2 fue el mejor de forma general y en escritura aleatorea. JFS es muy malo para la escritura aleatorea pero bueno en escritura lineal con archivos pequeños. XFS es la mejor opción para manejar archivos grandes.
Queda pendiente investigar el sistema de archivos Reiser4 que resulta muy prometedor pero que implica conseguir un kernel vanilla, parcharlo y compilarlo.