xfs
[Top] [All Lists]

Re: benchmarks

To: linux-xfs@xxxxxxxxxxx
Subject: Re: benchmarks
From: Federico Sevilla III <jijo@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 14 Jul 2001 02:53:47 +0800
Cc: reiserfs-list@xxxxxxxxxxx
In-reply-to: <Pine.LNX.4.33.0107130921430.29969-100000@xxxxxxxxxxxxxxxxxxx>
References: <Pine.LNX.4.33.0107130921430.29969-100000@xxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Internet Messaging Program (IMP) 2.3.7-cvs
(Note: original message seen in the XFS mailing list. Reply cross-posted to 
ReiserFS mailing list to prevent any occurences of "backstabbing" which I abhor)

Quoting "P.Dixon" <P.Dixon@xxxxxxxxx>:
> Any idea why xfs appears to be very much slower than reiserfs with these
> benchmarks:
> http://www.namesys.com/benchmarks/mongo/2.4.5-xfs-ext2_vs_reiserfs.html
> Admittedly, the benchmarks were done by namesys...

There are a number of reasons why this is so:

Zeroth, XFS was probably not tweaked and was just the default, not to mention 
release 1.0 (although I cannot qualify this as I have not found any pertinent 
information). XFS has gone quite a significant distance since release 1.0 with 
release 1.0.1 and the current CVS snapshots.

First the mongo.pl benchmark was written by Hans Reiser (I think, or at least 
his team) for testing ReiserFS in particular. It has been used for testing 
other filesystems as well, but it started out as a test for ReiserFS (comparing 
it with ext2fs, I think).

Second, ReiserFS was developed when there was no other journalling filesystem 
available for Linux. It was an alternative to ext2fs that had (and still has) 
rather poor handling for a lot of small files. Poor handling in that because of 
static inode allocation you can only handle so many of these small files, and 
you waste a lot of space in the process. ReiserFS does not have any of these 
limitations. Together with tail packing, you can dramatically reduce the space 
used by directory trees with a lot of small files. ReiserFS is also fast 
compared to ext2fs, which was its initial objective. No, it's not just fast, 
it's MUCH MUCH FASTER (particularly on modern machines with ample CPU).

Because ReiserFS was designed to handle the area where ext2fs was lacking 
(small files), the mongo.pl benchmark was designed to test this functionality. 
If you will notice the filesizes are unnaturally small, with the largest at 
100kb. Not so small, but still relatively small, right?

ReiserFS is ABSOLUTELY GREAT for what it was designed for: lots and lots of 
small files. These include Squid caches, especially. Because of XFS's slow 
deletes (which the mongo.pl correctly shows as previously mentioned), ReiserFS 
is also good when you will be deleting trees with a lot of files regularly. 
This includes my deleting /usr/src/linux-2.4.x-acy to create a 
new /usr/src/linux.vanilla which I will patch with a later ac patch.

You will notice, however, that results comparing ReiserFS and XFS give XFS the 
lead as the filesizes increase particularly in create and read speeds. Although 
because the mongo.pl benchmark was not designed to handle large files, we don't 
see this data progress and cannot make ample hypotheses testing (with the null 
hypothesis of course that ReiserFS is much faster than XFS no matter what the 
filesize).

As of yet I cannot qualify the discussions between both ReiserFS and XFS camps 
(I am part of both mailing lists as I use both filesystems) about the 
desireability of the fact that ReiserFS uses significantly much more CPU than 
XFS. I agree with the ReiserFS camp in that CPU useage is not bad per-se, 
because of the fact that CPU speed increases much more dramatically than drive-
speed or seek time does (someone posted a statistic about this in the last 
decade in the ReiserFS list). If CPU can be used to increase the performance of 
the filesystem, why the hell not, I say. This does not imply that higher CPU 
use makes a filesystem better than the other, though. If XFS can outperform 
ReiserFS in larger files without having to use as much CPU then I think that is 
a great plus for XFS.

I am of personal opinion that because XFS was designed to handle image files 
and other files larger than the small ones ReiserFS was designed for, we will 
see an increase in performance as size increases. For most database and data 
storage applications, this should be a plus. The fact that XFS is much MUCH 
slower than ReiserFS on deletes should not matter as large tree deletions 
should not be a part of normal day-to-day life of a data storage partition.

I am truly interested to find out about the benchmark results that Mike Gigante 
mentioned he would post soon (on the XFS mailing list). I agree that they will 
be interesting. This doesn't make me look down on ReiserFS, though. I am sure 
it has its plusses. Then of course there's the fact that they're obviously 
designed to handle different load and file types.

For your Squid cache, don't go XFS, but instead go ReiserFS. It will do a great 
job there. For your Samba or NFS partition, go XFS and not ReiserFS. Aside from 
the fact that ReiserFS is having problems with NFS (and SFS which runs on top 
of NFS), ReiserFS expects to have EA and ACL support only in ReiserFS v4 (which 
looks exciting, BTW) which is due at least a year from now as per Hans Reiser's 
estimations.

For those interested, DARPA supposedly sponsored encryption support to be built 
into ReiserFS v4. Still to be seen, of course, but I think we should all be 
happy about this. Like the lead developers of both filesystems 
mentioned "threads ago", XFS and ReiserFS are not competition to each other. 
Instead they both provide what makes Linux a continually more viable platform 
in this world where greed and closed-source applications still take the lead in 
a number of ways. (Read: we're not fighting each other, we have a common alien 
enemy). :)

 --> Jijo

-- 
Federico Sevilla III  :: jijo@xxxxxxxxxxxxxxxxxxxx
Network Administrator :: The Leather Collection, Inc.


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