Good idea to cross-post!
For the benefit of the Reiser list, I am running a diverse set of f/s
benchmarks with a number of different XFS 'configurations'. I am doing so
after some conversations at a local Linux users group - Neither mongo, nor
iozone/bonnie are either comprehensive enough at measuring overall f/s
performance or realistic simulations of real world file system usage
(except in limited cases).
I will be also running them with Ext2 and with reiserFS and will
post the results somewhere. This will be in a week or two from now...
Michael Gigante R&D Software Engineer mg@xxxxxxxxxxxxxxxxx
SGI Performance Tools Group, +61 3 9834 8233
Melbourne Australia V-Net: 524-8233
On Sat, 14 Jul 2001, Federico Sevilla III wrote:
> (Note: original message seen in the XFS mailing list. Reply cross-posted to
> ReiserFS mailing list to prevent any occurences of "backstabbing" which I
> 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
> 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
> 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
> 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
> 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
> 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),
> 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
> lead as the filesizes increase particularly in create and read speeds.
> because the mongo.pl benchmark was not designed to handle large files, we
> see this data progress and cannot make ample hypotheses testing (with the
> 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
> (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
> 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
> 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
> 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
> mentioned he would post soon (on the XFS mailing list). I agree that they
> 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
> job there. For your Samba or NFS partition, go XFS and not ReiserFS. Aside
> 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
> looks exciting, BTW) which is due at least a year from now as per Hans
> For those interested, DARPA supposedly sponsored encryption support to be
> 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
> a number of ways. (Read: we're not fighting each other, we have a common
> enemy). :)
> --> Jijo
> Federico Sevilla III :: jijo@xxxxxxxxxxxxxxxxxxxx
> Network Administrator :: The Leather Collection, Inc.