Análisis del sistema de archivos JFS vs XFS

Benchmarks de dos discos duros parecidos usando JFS (IBM) y XFS (SGI)

ACTUALIZACIÓN: A pesar de que en benchmarks el JFS es algo más rápido, es más inestable con el tiempo y sus utilidades de recuperación (fsck.jfs) no recuperan de todos los errores del sistema; llegará el momento que no puedas montar la partición. No lo aconsejo para almacenar información importante; si fsck.jfs da el error "CANNOT CONTINUE", lo mejor es usar el Linux JFS Partition Recovery de Nucleus para Windows o compilar jfsrec (a mí no me compilaba) y cambiar de sistema de archivos.

Voy a aprovechar que tengo dos discos prácticamente iguales con sistemas de archivos diferentes para hacer una comparación entre ambos sistemas. Cuando estuve utilizando JFS ya me sorprendió por su velocidad al iniciar el sistema, pero vayamos a los números y analicemos si mi impresión era la correcta.

Las pruebas se han realizado en un equipo con un procesador Via C7 2Ghz (equivalente a un Celeron 1,5 Ghz) con 1 GB Ram 533Mhz FSB y kernel 2.6.21.

Hardware


Ambos discos duros tienen los mismos datos; se copió el contenido del disco JFS al XFS por lo que el primero puede estar algo fragmentado (un 2% ya que estuvo casi todo el tiempo al 90% de ocupación). Este dato, y el hecho de que el disco con JFS sea algo más rápido se tendrá en cuenta a la hora de restar o añadir algo de valor a los resultados.

Primero se indican datos para poder comprobar las diferencias entre ambos discos duros SATA. En ninguno de los dos se aplicó ninguna optimización con hdparm; sino que tiene las opciones por defecto marcadas por la distribución, en este caso kubuntu 7.04.

SDB= Disco viejo con JFS
SDA= Disco nuevo con XFS

Información del disco viejo (sólo cambia modelo y firmware):

$ sudo hdparm -i /dev/sdb


Model=MAXTOR STM3250820AS , FwRev=3.AAE , SerialNo= 6QE1CVFV
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI- 4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

Información del disco nuevo:

$ sudo hdparm -i /dev/sda

Model=MAXTOR STM3250310AS , FwRev=3.AAA , SerialNo= 6RY0VNM0
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

Como vemos en los siguientes test de velocidad, el sdb es un 11,5% más rápido (se realizaron 3 pruebas, dejando la mejor) por lo que lo tendremos en cuenta:

$ sudo hdparm -tT /dev/sdb


Timing cached reads: 470 MB in 2.01 seconds = 234.34 MB/sec
Timing buffered disk reads: 234 MB in 3.02 seconds = 77.57 MB/sec
david@pcimanol:~/disco$ sudo hdparm -i /dev/sdb6

$ sudo hdparm -tT /dev/sda

Timing cached reads: 472 MB in 2.00 seconds = 235.43 MB/sec
Timing buffered disk reads: 206 MB in 3.00 seconds = 68.57 MB/sec
david@pcimanol:~/disco$ sudo hdparm -tT /dev/sda

Diferentes pruebas realizadas:

Copia del directorio del kernel (muchos archivos pequeños):
XFS:
sudo time cp -R /usr/src/linux/* /tmp/

2.00user 47.88system 6:24.75elapsed 12%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+507minor)pagefaults 0swaps

JFS:
david@pcimanol:~/prueba$ sudo time cp -R /home/david/disco/usr/src/linux/* /home/david/disco/mnt/

1.60user 41.59system 2:59.92elapsed 24%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+542minor)pagefaults 0swaps

Borrado del directorio kernel:
XFS:
david@pcimanol:/usr/src$ sudo time rm -rf linux-2.6.20.5/

0.25user 12.00system 2:24.49elapsed 8%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+229minor)pagefaults 0swaps

JFS:
david@pcimanol:/usr/src$ sudo time rm -rf linux-2.6.20.5/

0.08user 3.99system 0:51.70elapsed 7%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+229minor)pagefaults 0swaps

Benchmark de creación de archivos grandes:
(Para este benchmark compila el programa.c indicado al final)

XFS:
david@pcimanol:~/prueba$ ls
crear programa.c
david@pcimanol:~/prueba$ sudo time ./crear
1
1+0 registros de entrada
1+0 registros de salida
1048576 bytes (1,0 MB) copiados, 0,00367756 segundos, 285 MB/s
10
10+0 registros de entrada
10+0 registros de salida
10485760 bytes (10 MB) copiados, 0,0763831 segundos, 137 MB/s
100
100+0 registros de entrada
100+0 registros de salida
104857600 bytes (105 MB) copiados, 0,464523 segundos, 226 MB/s
250
250+0 registros de entrada
250+0 registros de salida
262144000 bytes (262 MB) copiados, 3,95784 segundos, 66,2 MB/s
500
500+0 registros de entrada
500+0 registros de salida
524288000 bytes (524 MB) copiados, 7,07681 segundos, 74,1 MB/s
0.05user 2.38system 0:11.91elapsed 20%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2major+2735minor)pagefaults 0swaps

JFS:
david@pcimanol:~/prueba$ sudo time ./crear
1
1+0 registros de entrada
1+0 registros de salida
1048576 bytes (1,0 MB) copiados, 0,108979 segundos, 9,6 MB/s
10
10+0 registros de entrada
10+0 registros de salida
10485760 bytes (10 MB) copiados, 0,0557353 segundos, 188 MB/s
100
100+0 registros de entrada
100+0 registros de salida
104857600 bytes (105 MB) copiados, 0,474631 segundos, 221 MB/s
250
250+0 registros de entrada
250+0 registros de salida
262144000 bytes (262 MB) copiados, 1,20296 segundos, 218 MB/s
500
500+0 registros de entrada
500+0 registros de salida
524288000 bytes (524 MB) copiados, 19,5337 segundos, 26,8 MB/s
0.04user 3.33system 0:21.45elapsed 15%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2736minor)pagefaults 0swaps

Resumen gráfico de las pruebas:

COMANDO	XFS (SDA) 12% FASTER
	CPU	TIME (min,sec)
sudo time cp -R /usr/src/linux/* /tmp/	12%	6’24’’
sudo time rm -rf linux-2.6.20.5/	8%	2’24’’
sudo time ./crear	20%	11’91’’

COMANDO	JFS (SDB)
	CPU	TIME (min,sec)
sudo time cp -R /usr/src/linux/* /tmp/	24%	2’59’’
sudo time rm -rf linux-2.6.20.5/	7%	0’51’’
sudo time ./crear	15%	21’45’’

El script "crear" ha sido cogido de la página de Bulma, crea archivos grandes con datos aleatorios, creado por Ricardo y modificado para que cree archivos aún más grandes:

#include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <stdio.h> #include <string.h> #include <errno.h> #define NFILES 5 #define NCYCLES 100 #define NTRIES 100 #define BSIZE 16536 char *filenames[NFILES] = {"1.dat", "10.dat", "100.dat", "250.dat", "500.dat" }; char *dir = "/mnt/"; main() { char buffer[BSIZE]; int cycle, try, fd, i, fsize, bytes; char filename[256]; struct stat st; srand(time(NULL)); for(cycle=0;cycle<NCYCLES;cycle++) { sprintf(filename, "%s%s", dir, filenames[rand() % NFILES]); if((fd=open(filename, O_RDWR)) < 0) { fprintf(stderr, "Couldn't open file %s, stop\n", filename); exit(0); } fstat(fd, &st); fsize=st.st_size; printf("Trying %s, size: %d\n", filename, fsize); for(try=0; try<NTRIES; try++) { i = rand() % fsize; seek(fd, i, SEEK_SET); bytes = read(fd, buffer, BSIZE); // printf("read %d bytes\n", bytes); if (rand() % 4 == 0) { lseek(fd, i, SEEK_SET); bytes = write(fd, buffer, BSIZE); fsync(fd); if (bytes < 0) { fprintf(stderr, "Error %s\n", strerror(errno)); } } } } }

Conclusión:

Parece que gana el sistema JFS de forma aplastante en cuanto a la lectura/borrado de archivos pequeños (la diferencia de 4 minutos en copiar el kernel es increíble), y en cambio en la creación de archivos grandes tarda el doble (poco habitual en el uso diario).

Por otro lado, en kernels linux recientes se ha mejorado la velocidad del sistema XFS, por lo que estas diferencias se mitigarían un poco.

A la hora de elegir un sistema de archivos debemos tener en cuenta también su estabilidad, y por mi experiencia el JFS es un sistema minoritario pensado para servidores y que no ha sido bien testeado a la hora de recuperarse ante un fallo de alimentación o de hardware como es habitual en un equipo de escritorio. Aunque el XFS también tiene algún que otro fallo (sólo hay que ver sus listas de correo). Si esto te preocupa, el sistema más probado es el EXT3 (y también el más lento de los 3 sistemas mencionados).

Tenemos que tomar los datos con precaución por las diferencias de los discos; el utilizado para XFS es una evolución, aunque por los resultados es algo más lento, podría ser que el fabricante ha decidido alargar la vida del disco (para que pase los 2 años de garantía) forzando menos los elementos. Por otro lado por la mejora de la tecnología, el nuevo es más fino y ligero, aunque de la misma capacidad.