[Top] [All Lists]

Re: Benchmarking ReiserFS, ext2, XFS

To: Federico Sevilla III <jijo@xxxxxxxxxxxxxxx>
Subject: Re: Benchmarking ReiserFS, ext2, XFS
From: Steve Lord <lord@xxxxxxx>
Date: Wed, 16 May 2001 09:51:38 -0500
Cc: Linux XFS Mailing List <linux-xfs@xxxxxxxxxxx>
Cc: reiserfs-list@xxxxxxxxxxx
Comments: In-reply-to Federico Sevilla III <jijo@xxxxxxxxxxxxxxx> message dated "Wed, 16 May 2001 20:24:52 +0800."
References: <Pine.LNX.4.21.0105161929390.1579-100000@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Thanks for the info, I just took a look at the reiserfs archive,
and subscribed to the list. Interesting that no one on the xfs
list was contacted about this with questions such as how to configure
xfs etc (I could say mindcraft here but that might be inflamatory ;-).
It would certainly be interesting to see which config options were
used in the filesystem part of the kernel compile. The RPMs were
shipped with all features turned on which will impact performance,
turning off quotas and acls would be a good thing.

Anyway, I am not surprised reiserfs wins on small file
tests, someone independent might want to ask what happens if you
pull the power in the middle of the test. I suspect the answer on
reiserfs is that almost nothing is on the disk after reboot, the file
creation/removal part of bonnie++ (30000 files created and removed
twice) can complete without disk I/O on reiserfs.

I will download the mongo tests and try them out myself.

As for the ac kernels - I challenge anyone who is working for a living
and has other things to do to keep something the size of XFS upto date
with Alan's kernels - I have seen 3 of those in one day. Plus changes
tend to come and go, and XFS does have its fingers in the VM system,
getting those in sync is not always straight forward, so it is not a
matter of apply a patch and go.


p.s. For the filesystem mkfs and mount part of mongo.pl I would recommend

    if ( $FILESYSTEM eq "xfs" ) {
        system("mkfs -t xfs -f -l size=16384b $DEVICE") ;
        system("mount -o logbufs=4,osyncisdsync $DEVICE $TESTDIR") ;

This increases the journal size from the default, mounts with 4 in core log
buffers instead of 2 and makes sure that O_SYNC has the same behavior as
it does on ext2. For the release kernel I would also add biosize=13 to
the mount options, this no longer makes a difference in the cvs kernels.

> Hi everyone,
> Following the link that Ed McKenzie <eem12@xxxxxxxxxxx> sent, I read the
> ReiserFS list archives searching for benchmarks comparing the performance
> of ReiserFS, ext2, and XFS.
> Here are results of benchmarks comparing the three using mongo.pl (what
> seems to be a pretty extensive benchmark test suite that is has been used
> by the ReiserFS development team to measure the performance of their
> filesystem since they started, it seems).
> <http://www.informatik.uni-frankfurt.de/~loizides/reiserfs/ext2-reiserfs-xfs.
> html>
> These test were done on a machine running RedHat 7.1 with the Linux kernel
> 2.4.3, with a Duron 700MHz CPU, 128MB RAM, and a 9GB SCSI HDD. Filesystem
> versions compared are: Ext2 version 0.5b, ReiserFS version 3.6.25, and XFS
> version 1.0.

I would ask exactly what was done to apply the 1.0 patches to 2.4.3, this
is not what we released, was this actually the rpm, or was it downloaded
from the cvs tree?

> Perhaps the XFS developers would have something to say about the test
> results? Speculations on how much better the latest CVS copy of XFS will
> perform on Linux 2.4.4?
> I do not have a machine to do benchmarks, but if someone out there has, it
> would be great to see an updated comparison.
> Also I'd like to relay the comments of someone on IRC that I got to chat
> with when trying to find someone to talk to about these benchmarks. He/she
> said that his/her only real irk with XFS is that the developers aren't
> able to keep track of the -ac patches. As a consequence, he is in constant
> need of fixing patch rej's. ReiserFS is at an advantage here, because it
> has been incorporated into the Linux 2.4 kernel tree.
> Comments?
>  --> Jijo
> --
> Linux, MS-DOS, and Windows NT ...
> ... also known as the Good, the Bad, and the Ugly

<Prev in Thread] Current Thread [Next in Thread>