BULMA

Bergantells Usuaris de GNU/Linux de Mallorca i Afegitons   |   Bisoños Usuarios de GNU/Linux de Mallorca y Alrededores
CONTENIDOS
. Jornadas de software libre
. Version para PDA
. Enlaces breves
. La asociacion
. Los mas leidos
. Autores [Actividad]
. Ultimos Comentarios
. Todos los titulares!
. Estadisticas
. Guia de estilo
. ¿Sugerencias?
. Wiki
. XML [Ayuda]
Listas de correo
. Archivos bulmailing
. Archivos BulmaGes
Radio libre :-)
. Des de la Xarxa (Archivos)
. Mallorca en Xarxa
Busquedas

+ Enlaces Linux
Ultimos kernels
(22/09/2014 15:16:16)
    
Google


En bulma.net
En internet
Ext2, ReiserFS and XFS Benchmarks (136588 lectures)
Por Ricardo Galli Granada
gallir (http://mnm.uib.es/gallir/)
Creado el 22/05/2001 04:46 modificado el 22/05/2001 04:46

First of all, there is no a clear winner, XFS is better in some aspects or cases, ReiserFS in others, and both are better than Ext2 in the sense that they are comparable in performance (again, sometimes faster, sometimes slightly slower) but they a journaling file systems, and you already know what are their advantages... And perhaps the most important moral, is that Linux buffer/cache is really impressive and affected, positively, all the figures of my compilations, copies and random reads and writes. So, I would say, buy memory and go journaled ASAP...   

After our site was Slashdotted when Beowulf reported some very simple tests among ReiserFS, XFS, JFS and Ext2, we received comments from Hans Reiser, his collaborators and other readers in Internet. The major criticism was that the report was in Spanish, so here you have new ones in English (rapidly written, without running any spelling or grammar checker, we've got bored after many mkfs...mount...time time time umount... ;-).


Pagina1/1

Mongo Benchmarks

The original author of the previous test, Guillem Cantallops, carried up new benchmarks (XFS vs. ReiserFS vs. JFS vs. Ext2) but this time using the Mongo script provided by Hans Reiser. The first benchmark was done on a slow CPU machine (Cyrix MII 233MHz, 128MB SDRAM, Samsung SV0844A hard disk) and we noted that, although ReiserFS was the fastest for reading small size files (up to 100 or 1000 bytes), it was extremely slow for bigger ones (the files' average size of a vanilla Red Hat or Debian distribution is about 16 KB).

We weren't very convinced of the validity of the benchmark results due to the old CPU, so Guillem repeated the benchmarks (XFS, ReiserFS, Ext2) on a Pentium III, 800 Mhz, 512MB SDRAM and a Seagate ST330621A hard disk. Although the results are relatively comparables to the previous benchmark, they are much closer to each other in the second test.

Linux Kernel Compilation

I also wanted to test the three file systems but compiling the kernel. I run three times the test, which consisted of a cp, make bzImage, make clean and rm -r

According to some comments from Hans Reiser that the use of tails for storing data belonging to other files can lower the performance (they have implemented a new layout policy called Plan A that missed the 2.4 code freeze and will be in Reiser4), we tested with the default mount option (using tails) and with mount -o notail.

The average of the three execution are as follows:

Command Kernel Compilation 
(time in seconds)
XFS ReiserFS (notail) ReiserFS Ext2
CPU Real CPU Real CPU Real CPU Real
cp -a /usr/linux /mnt/ 8.57 29.40 4.81 5.99 5.49 6.45 2.55 17.90
make bzImage 289.24 292.067 289.33 291.14 289.38 297.27 288.99 293.69
make clean 1.00 1.37 0.50 0.50 0.50 0.50 0.44 0.46
rm -rf /mnt/linux 2.14 11.41 1.06 1.07 1.05 1.05 0.19 0.19

 The test was done on the same machine: Pentium III, 800 Mhz, 512MB SDRAM and a Seagate ST330621A. For every run, the partition (7GB) was cleaned (rm -rf *), unmounted and mounted again. Because the availability of the data in the Linux cache may affect the time measured for cp -a, I repeated the command a couple of times before doing the real measurements (there was a huge variance with the first time). 

Random lseeks, reads and writes

The previous tests have shown me that the three file systems, besides the very slow copy in XFS, are very close in terms of wall-clock and CPU times. But I wanted to try also what would happen in a "small database real case", so to speak. The difference of the access pattern of a database is that most RDMS do a lot of lseek and read on files of different size (table data and indices) and sporadically the write new values into the DB pages. Sometimes, a fsync follows immediately after a write and the files may increase their size very slowly when new data is inserted.

So, I've created five files of different sizes: 1, 10, 100, 250 and 500 MBytes (I could try with bigger sizes, but the benchmarks would take hours to complete...):

 
#! /bin/sh 
for i in 1 10 100 250 500 
do 
        echo $i 
        dd if=/dev/zero of=/mnt/$i.dat bs=1M count=$i 
        chmod ugo+rw /mnt/$i.dat 
done 

Then I run a small program random.c (find it at the end of the page) that cycled (100 times) through the five files, and for each cycle, it accessed 100 times to random (lseek) locations of the file, read a buffer of 16KB and then in the 25% of the cases, it lseek'ed back to the previous position, wrote the buffer and the forced a fsync of the file.

To obtain the times, I first mounted the file system, created the files with the previous script and run three times the program before to get the cache populated as fair as possible. Then I run the random program three times and took the average of the three executions:

Read/Write/Fsync Tests in seconds
(random.c)
  XFS ReiserFS
(notail)
Ext2
CPU 1.30 1.55 1.16

Real

62.50 66.91 65.32

Conclusions

I noted disparate results among the different base file size Mongo benchmarks, so I wanted to see what would happen in a real scenario (at least for us) where the Linux VFS and  cache techniques can improve enormously the global performance of the system.

In the case of the kernel compilation, Ext2 has a very low performance for copying files, for the other tests ReiserFS with notail option is the winner but the times are very close to Ext2 and XFS, the difference is less than 2% for make bzImage.

In the last case, where I mixed lseek, read, write and fsync on files of different sizes, the winner is XFS but for a very small difference, less that 8% compared to ReiserFS.

Analysing all benchmarks, it seems that for the common cases, ReiserFS and XFS have a better performance that Ext2 and with the added value of a journaled file system.

What can I say? If you are a home user or own a small server and a relatively fast CPU, use ReiserFS or XFS, both were very stable in our tests and the differences are almost inexistent.

 

--ricardo

 


 
random.c
 
#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)); 
        } 
      } 
    } 
  } 
} 

Imprimir
Version para
imprimir

Imprimir
Version
PDF
Comentarios
Es posible que se hayan omitido algunos comentarios considerados poco constructivos
1.  Re:Ext2, ReiserFS and XFS Benchmarks (22/05/2001 17:58, #1377)
  Por: Jeronimo
Tengo un problema con un ext2fs y me estoy planteando migrar al Kernel 2.4 y al XFS de rapidez ya se como funciona, pero en temas de seguridad y lo que mas me importa el limite maximo de tamaño de fichero, el ext2 tiene 2Gb como maximo y ya tengo varios ficheros con 2Gb y quisiera estar seguro de que soporta mas de 2Gb alguna comparativa de tamaños de particiones, ficheros, nombres, etc... gracias.

 
2.  Re:Ext2, ReiserFS and XFS Benchmarks (19/05/2003 15:41, #14500)
  Por: El cobarde anónimo
Mandame pure un ficheros a mi. Grazias

 
3.  Re:Ext2, ReiserFS and XFS Benchmarks (22/05/2001 18:02, #1378)
  Por: Daniel (http://nl.linux.org/~phillips/)

The measured create and rename times for Ext2 look pretty silly, don't they?
OK, I know that my htree directory index patch isn't part of Ext2 yet, but at
least lets mention that this is a solved problem.

http://nl.linux.org/~phillips/htree

--
Daniel

 
4.  Re:Ext2, ReiserFS and XFS Benchmarks (22/05/2001 18:42, #1379)
  Por: Beowulf (http://starkmad.yi.org:8888/)
Jeronimo: el XFS es especialmente bueno con ficheros grandes, cuanto más grandes mejor. El XFS se usa en máquinas de SGI desde hace años y desde luego manejan ficheros de bastante más de 2GB ;-)

Se supone que la implementación para Linux es compatible con particiones XFS de SGI (aunque el código para Linux es casi todo nuevo) y me imagino que los chicos de SGI lo habrán probado todo con ficheros grandes porque es donde se porta mejor. En

http://linux-xfs.sgi.com/projects/xfs/

encontrarás todos los detalles que necesitas. Aunque me temo que el parche "oficial" más actualizado es para el kernel 2.4.3...

 
5.  Re:Ext2, ReiserFS and XFS Benchmarks (22/05/2001 20:06, #1382)
  Por: El cobarde anonimo
Y la traduccion en castellano!?!

 
6.  Re:Ext2, ReiserFS and XFS Benchmarks (23/05/2001 14:07, #1390)
  Por: Beowulf (http://starkmad.yi.org:8888/)
Acabo de ver que salimos en barrapunto... ahora que se nos ocurre hacerlo en inglés por si vuelve la oleada de USA, salimos primero en barrapunto y a lo mejor ni salimos en slashdot X'-DDDD

Este Murphy, siempre haciendo de las suyas :-P

 
7.  Re:Ext2, ReiserFS and XFS Benchmarks (23/05/2001 14:07, #1391)
  Por: Beowulf (http://starkmad.yi.org:8888/)
Además, hay que tener en cuenta que esta vez los benchmarks son mil veces mejores (por lo menos :-)

 
8.  Re:Ext2, ReiserFS and XFS Benchmarks (23/05/2001 14:07, #1392)
  Por: Manuel Molina Cuberos (http://easy.to/deluxe)
Hola. Ante todo, correccion a Beowulf: Parches quiza no, pero si te bajas el CVS de desarrollo tendras el 2.4.4-xfs :-))

He podido comprobar personalmente que con ficheros grandes XFS se comporta bien. Ahora, cuando configure innd en mi maquina probaremos que tal se comporta con ficheros pequeños. Un servidor de news como este tiene un monton muy grande de ficheros cuyo tamanio medio sera de 4 / 6 kb.

Un saludo,

 
9.  Re:Ext2, ReiserFS and XFS Benchmarks (23/05/2001 22:00, #1401)
  Por: Beowulf (http://starkmad.yi.org:8888/)
Bueno, yo hablaba de releases oficiales, no de snapshots del CVS ;-)

Ficheros de 4 a 6KB??? Lo has intentado con ReiserFS?

 
10.  Re:Ext2, ReiserFS and XFS Benchmarks (24/05/2001 00:43, #1402)
  Por: baldusi
Puedo comentar que me parece muy interesante pero falta la prueba "ácida"?
El asunto es que lo interesante sería en mitad de las pruebas desenchufar las máquinas un par de veces y tomar el tiempo de arranque y la probabilidad de fallos. Quien sabe. Capaz que se podría simular éste mismo server (que no se cayó la otra vez por falta de capacidad sino que no se habían coordinado el máximo número de conecciones del PostgreSQL con las del Apache) cuando es eslashdoteado (existe?) y cortar en ese momento la corriente.
Cuando estoy muy deprimido pienso en un sistema que se recupere de esa sin problemas.

Saludos criollos,
Baldusi
PD: La Boleadoras también son del LUGAR

 
11.  Re:Ext2, ReiserFS and XFS Benchmarks (24/05/2001 00:48, #1403)
  Por: gallir (http://m3d.uib.es/~gallir/)
Yo lo probé varias veces (lo de desenchufar) y no tuve ningún problema, un PIII me arranca en unos 15-20 segundos, con todos los servicios.

Y no son boleadores, son hondas, como esas de las películas de gladiadores. Las hondas son originarias de aquí, lo usaban los "balearicos", que dicen las lenguas que eran mercenarios de los griegos y romanos.

Un abrazo.

--ricardo

 
12.  y JFS para quien? (28/05/2001 11:18, #1437)
  Por: pecador de la pradera
alguien ha probado JFS? porque no se ha incluido JFS en la comparativa?

http://freshmeat.net/projects/jfs/

 
13.  Re:Ext2, ReiserFS and XFS Benchmarks (28/05/2001 11:32, #1438)
  Por: gallir (http://m3d.uib.es/~gallir/)
En los benchmarks Mongo de Beowulf _sí_ está el JFS y no se ha seguido probando proque ha dado problemas al no ser una version estable.

--ricardo

 
14.  ReiserFS, XFS, JFS, ext2 ....¿pero y ext3? (28/05/2001 15:17, #1443)
  Por: Ibantxuyn
El articulo mola, reiserfs mola aun mas, pero donde
puñetas está el sucesor de ext2, el ext3 ??
Creo haber leido que en rpmfind tienen puesto ext3
y sin problemas, pero no conozco a nadie que lo tenga
puesto.
Es mejor, peor, igual, que mas da .. ¿??¿? jeje.

Saludos a tod@s :))

 
15.  Re:Ext2, ReiserFS and XFS Benchmarks (28/05/2001 15:29, #1444)
  Por: gallir (http://m3d.uib.es/~gallir/)
Al momento de hacer estas pruebas el ext3 no estaba estable todavía, sin embargo ya lo haremos.

El ext3 no es un sistema como el Reiser, XFS o JFS, sino que es una extensión del ext2 para soportar journaling.

--ricardo

 
16.  Re:Ext2, ReiserFS and XFS Benchmarks (05/06/2001 18:21, #1516)
  Por: Eric Dahan
Unos comentarios sobre las pruebas efectuadas en su sitio.

Primeramente, el test ha sido hecho con un disco IDE (de velocidad maxima de +-320Mb/sec) y un CPU muy rapido, esto puede provocar que el test sea disco "bound". Quiero decir que los tiempos muy comparables que han tenido entre los diferentes "file systems" pueden estar ocasionados por el hecho de haber utilisado un disco de menor velocidad. Mismo si no todo el mundo tiene discos SCSI imagino que seria interesante para completar el ejercicio que han empezado de probarlo (la gente que utilisan Linux en un servidor de noticias por ejemplo, imagino, que pagarian la diferencia entre los dos tipos de discos.
Mi recomendacion seria de hacer la misma prueba pero con un disco SCSI, y mismo utilisando el CTQ (Command Tag Queueing del disco para mallor velocidad)

Imagino que si ustedes quieren asegurarse que las pruebas de Ext2, ReiserFS and XFS son buenas deben asegurarse que el hardware (como hicieron para el CPU) es capaz de permitir al mas rapido "file system" de destacarse.

-- Eric

 
17.  Re:Ext2, ReiserFS and XFS Benchmarks (05/06/2001 18:45, #1517)
  Por: gallir (http://m3d.uib.es/~gallir/)
Hola Eric,
gracias por tu comentario...

El principal problema que veo es como obviar el buffer/cache del Linux, ya que si te fijas en la compilación del kernel, es más "CPU bound" que disco.

Pero tampoco sé si tiene mucho sentido en preocuparse en eliminar la influencia del cache, ya que lo normal es que esté funcionando. Lo que si podría dar valores distintos es la prueba de accesos y modificacions aletorias a ficheros grandes, de más de 1 GB.

Un abrazo.


--ricardo

 
18.  Mount reisesfs (17/06/2002 02:03, #6770)
  Por: BOT
Hola amigos! tengo un problema con sistema reiserfs ... se demora en montar bash-2.05# time mount /dev/hdb4 /downloads/ real 0m1.263s user 0m0.010s sys 0m0.040s a que puede deberse esto ?? .. algun problema de tabla de particiones ?? o es normal que el reiser trabaje de esta forma .. gracias

 
19.  Re: Ext2, ReiserFS and XFS Benchmarks (12/09/2003 16:42, #17075)
  Por: Claunia (http://80.59.103.181)
Where can I upload the results of test I did using iozone for XFS, JFS, ReiserFS and ext3fs? Donde puedo subir los resultados de un test que hice con iozone sobre XFS, JFS, ReiserFS y ext3fs?

 
20.  Re: Ext2, ReiserFS and XFS Benchmarks (16/09/2004 23:27, #23309)
  Por: MAXMALY
la verdad es que yo usaba etx3 y la tuve que cambiar por reiserfs por problemas de perdida de datos en el fs etx3.yo tengo un disco scsi ultra y el reiserf es muy rapido y estable

 
GRACIAS
Distribuciones Universal
Por el servidor
Dpto. de Matematicas e Informatica
Calificacion
****
Vots: 29
Danos tu opinion:
**** Excelente
***0 Muy Bueno
**00 Bueno
*000 Regular
0000 Malo
Relacionados
. Próximos parches para ReiserFS
. Journal File Systems in Linux
. Sistemas de Ficheros con Journaling en Linux
. Reparticionat del disc dur: La passa més temuda pels nous linuxers.
. Mejorar el rendimiento en el Ext3
. El ext3 ha sido incluido en el kernel
. 2.4.11, buffer-cache y page-cache unificados
. Más benchmarks de sistemas de ficheros
. IBM libera la version 1.0 del jfs. Journaled File System
. Benchmarks entre Linux, Solaris, FreeBSD y Windows 2000
. Mongo Benchmarks
. Pruebas con XFS, ReiserFS, Ext2FS, y FAT32
. Silicon Graphic anuncia el pre-release 0.9 de XFS
SECCIONES
Noticia
Breve
Truco
Enlace
Participa
Proyecto
Articulo
Webbulma
Manoletada :-)
Seguridad
Modificado: 13/5/2014 23:49:28 | Tiempo Total: 0.041 segs | Kernel: Linux - i686 - 2.6.26-1-686 | Last boot: too much time ago!!
Powered by Apache    MySQL    PHP    Gimp