Rendimiento de los sistemas de archivos de bucle invertido

¿Alguien ha hecho alguna prueba de rendimiento / evaluación comparativa en sistemas de archivos de bucle invertido de Linux? ¿Cuál ha sido tu experiencia hasta ahora? ¿Hay alguna degradación grave en el rendimiento? ¿Qué tal la robustez?

http://freshmeat.net/articles/virtual-filesystem-building-a-linux-filesystem-from-an-ordinary-file

He hecho un poco de evaluación comparativa con operaciones de escritura en un dispositivo de bucle invertido. Aquí está la conclusión:

• Si sincroniza después de cada escritura, un dispositivo de bucle invertido funciona significativamente peor (casi el doble de lento).
• Si permite que el caché de disco un planificador de E / S haga su trabajo, casi no hay diferencia entre usar un dispositivo de bucle invertido y acceso directo al disco.

Resultados de referencia

Primero, ejecuté un punto de referencia en un dispositivo loopback en tmpfs de 8GB, y un dispositivo loopback dentro de ese dispositivo loopback ( con sincronización después de cada operación de escritura ):

ext4 en tmpfs:

Measured speed: 557, 567, 563, 558, 560, 559, 556, 556, 554, 557
Average speed : 558.7 MB/s  (min 554  max 560)

ext4 en extf en tmpfs:

Measured speed: 296, 298, 295, 295, 299, 297, 294, 295, 296, 296
Average speed : 296.1 MB/s  (min 294  max 299)

Claramente, hay alguna diferencia en el rendimiento cuando se utilizan dispositivos de bucle invertido con sincronización en escritura.
Luego repetí la misma prueba en mi HDD.
ext4 (HDD, 1000 MB, 3 veces):

Measured speed: 24.1, 23.6, 23.0
Average speed : 23.5 MB/s  (min 23.0  max 24.1)

ext4 en ext4 (HDD, 945MB):

Measured speed: 12.9, 13.0, 12.7
Average speed : 12.8 MB/s  (min 12.7  max 13.0)

El mismo punto de referencia en HDD, ahora sin sincronización después de cada escritura ( time (dd if=/dev/zero bs=1M count=1000 of=file; sync), medida como <size>/ <time in seconds>).
ext4 (HDD, 1000 MB):

Measured speed: 84.3, 86.1, 83.9, 86.1, 87.7
Average speed : 85.6 MB/s  (min 84.3  max 87.7)

ext4 en ext4 (HDD, 945MB):

Measured speed: 89.9, 97.2, 82.9, 84.0, 82.7
Average speed : 87.3 MB/s  (min 82.7  max 97.2)

(Sorprendentemente, el punto de referencia de bucle invertido se ve mejor que el punto de referencia de disco sin procesar, presumiblemente debido al tamaño más pequeño del dispositivo de bucle invertido, por lo tanto, se dedica menos tiempo a la sincronización real al disco)

Configuración de referencia

Primero, creé un sistema de archivos loopback de 8G en mi / tmp (tmpfs):

truncate /tmp/file -s 8G
mkfs.ext4 /tmp/file
sudo mount /tmp/file /mnt/
sudo chown $USER /mnt/

Luego establecí una línea de base al llenar el archivo loopback montado con datos:

$ dd if=/dev/zero bs=1M of=/mnt/bigfile oflag=sync
dd: error writing '/mnt/bigfile': No space left on device
7492+0 records in
7491+0 records out
7855763456 bytes (7.9 GB) copied, 14.0959 s, 557 MB/s

Después de hacer eso, creé otro dispositivo loopback en el dispositivo loopback anterior:

mkdir /tmp/mountpoint
mkfs.ext4 /mnt/bigfile
sudo mount /mnt/bigfile /tmp/mountpoint
sudo chown $USER /tmp/mountpoint

Y ejecutó el punto de referencia nuevamente, diez veces:

$ dd if=/dev/zero bs=1M of=/tmp/mountpoint/file oflag=sync
...
7171379200 bytes (7.2 GB) copied, 27.0111 s, 265 MB/s

y luego desmonté el archivo de prueba y lo eliminé:

sudo umount /tmp/mountpoint
sudo umount /mnt

(de manera similar para la prueba en el HDD, excepto que también agregué count=1000para evitar que la prueba llene todo mi disco)
(y para la prueba de no escritura en sincronización, ejecuté el tiempo ddy la syncoperación)

No he tenido problemas Todo ha sido sólido como una roca. La memoria caché del sistema de archivos y el planificador de E / S en Linux son lo suficientemente sensibles como para no hacer una diferencia notable entre pedir un disco directamente y pedir una sección de un archivo en un disco.