benchmark results
 

I've had the chance to use a testsystem here and couldn't resist running a
few benchmark programs on them: bonnie++, tiobench, dbench and a few
generic ones (cp/rm/tar/etc...) on ext{234}, btrfs, jfs, ufs, xfs, zfs.

All with standard mkfs/mount options and +noatime for all of them.

Here are the results, no graphs - sorry:
http://nerdbynature.de/benchmarks/v40z/2009-12-22/

Reiserfs is locking up during dbench, so I removed it from the
config, here are some earlier results:

http://nerdbynature.de/benchmarks/v40z/2009-12-21/bonnie.html

Bonnie++ couldn't complete on nilfs2, only the generic tests
and tiobench were run. As nilfs2, ufs, zfs aren't supporting xattr, dbench
could not be run on these filesystems.

Short summary, AFAICT:
- btrfs, ext4 are the overall winners
- xfs to, but creating/deleting many files was *very* slow
- if you need only fast but no cool features or journaling, ext2
is still a good choice :)

Thanks,
Christian.
--
BOFH excuse #84:

Someone is standing on the ethernet cable, causing a kink in the cable

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

benchmark results
 

On Thu, Dec 24, 2009 at 01:05:39PM +0000, Peter Grandi wrote:
> > I've had the chance to use a testsystem here and couldn't
> > resist
>
> Unfortunately there seems to be an overproduction of rather
> meaningless file system "benchmarks"...

One of the problems is that very few people are interested in writing
or maintaining file system benchmarks, except for file system
developers --- but many of them are more interested in developing (and
unfortunately, in some cases, promoting) their file systems than they
are in doing a good job maintaining a good set of benchmarks. Sad but
true...

> * In the "generic" test the 'tar' test bandwidth is exactly the
> same ("276.68 MB/s") for nearly all filesystems.
>
> * There are read transfer rates higher than the one reported by
> 'hdparm' which is "66.23 MB/sec" (comically enough *all* the
> read transfer rates your "benchmarks" report are higher).

If you don't do a "sync" after the tar, then in most cases you will be
measuring the memory bandwidth, because data won't have been written
to disk. Worse yet, it tends to skew the results of the what happens
afterwards (*especially* if you aren't running the steps of the
benchmark in a script).

> BTW the use of Bonnie++ is also usually a symptom of a poor
> misunderstanding of file system benchmarking.

Dbench is also a really nasty benchmark. If it's tuned correctly, you
are measuring memory bandwidth and the hard drive light will never go
on. :-) The main reason why it was interesting was that it and tbench
was used to model a really bad industry benchmark, netbench, which at
one point a number of years ago I/T managers used to decide which CIFS
server they would buy[1]. So it was useful for Samba developers who were
trying to do competitive benchmkars, but it's not a very accurate
benchmark for measuring real-life file system workloads.

[1] http://samba.org/ftp/tridge/dbench/README

> On the plus side, test setup context is provided in the "env"
> directory, which is rare enough to be commendable.

Absolutely. :-)

Another good example of well done file system benchmarks can be found
at http://btrfs.boxacle.net; it's done by someone who does performance
benchmarks for a living. Note that JFS and XFS come off much better
on a number of the tests --- and that there is a *large* number amount
of variation when you look at different simulated workloads and with a
varying number of threads writing to the file system at the same time.

Regards,

- Ted

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users

benchmark results
 

On Thu, 24 Dec 2009 at 16:27, tytso@mit.edu wrote:
> If you don't do a "sync" after the tar, then in most cases you will be
> measuring the memory bandwidth, because data won't have been written

Well, I do "sync" after each operation, so the data should be on disk, but
that doesn't mean it'll clear the filesystem buffers - but this doesn't
happen that often in the real world too. Also, all filesystem were tested
equally (I hope), yet some filesystem perform better than another - even
if all the content copied/tar'ed/removed would perfectly well fit into the
machines RAM.

> Another good example of well done file system benchmarks can be found
> at http://btrfs.boxacle.net

Thanks, I'll have a look at it and perhaps even integrate it in the
wrapper script.

> benchmarks for a living. Note that JFS and XFS come off much better
> on a number of the tests

Indeed, I was surpised to see JFS perform that good and XFS of course is
one of the best too - I just wanted to point out that both of them
are strangely slow at times (removing or creating many files) - not what I
expected.

> --- and that there is a *large* number amount
> of variation when you look at different simulated workloads and with a
> varying number of threads writing to the file system at the same time.

True, the TODO list in the script ("different benchmark options") is in
there for a reason :-)

Christian.
--
BOFH excuse #291:

Due to the CDA, we no longer have a root account.

_______________________________________________
Ext3-users mailing list
Ext3-users@redhat.com
https://www.redhat.com/mailman/listinfo/ext3-users