(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
> 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
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
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
Federico Sevilla III :: jijo@xxxxxxxxxxxxxxxxxxxx
Network Administrator :: The Leather Collection, Inc.