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
Hi, On Thu, 24 Dec 2009 02:31:10 -0800 (PST), Christian Kujau wrote:> 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.I looked at the log but couldn''t identify the error. Is that a disk full? Thanks, Ryusuke Konishi> 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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html-- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Which I/O scheduler are you using? Pretty sure that ReiserFS is a little less deadlocky with CFQ or another over deadline, but that deadline usually gives the best results for me (especially for JFS). Thanks, Teran On Thu, Dec 24, 2009 at 10:31, Christian Kujau <lists at nerdbynature.de> wrote:> 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 > -- > To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in > the body of a message to majordomo at vger.kernel.org > More majordomo info at ?http://vger.kernel.org/majordomo-info.html >
> I've had the chance to use a testsystem here and couldn't > resistUnfortunately there seems to be an overproduction of rather meaningless file system "benchmarks"...> 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: [ ... ]After having a glance, I suspect that your tests could be enormously improved, and doing so would reduce the pointlessness of the results. A couple of hints: * 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). BTW the use of Bonnie++ is also usually a symptom of a poor misunderstanding of file system benchmarking. On the plus side, test setup context is provided in the "env" directory, which is rare enough to be commendable.> Short summary, AFAICT: > - btrfs, ext4 are the overall winners > - xfs to, but creating/deleting many files was *very* slowMaybe, and these conclusions are sort of plausible (but I prefer JFS and XFS for different reasons); however they are not supported by your results as they seem to me to lack much meaning, as what is being measured is far from clear, and in particular it does not seem to be the file system performance, or anyhow an aspect of filesystem performance that might relate to common usage. I think that it is rather better to run a few simple operations (like the "generic" test) properly (unlike the "generic" test), to give a feel for how well implemented are the basic operations of the file system design. Profiling a file system performance with a meaningful full scale benchmark is a rather difficult task requiring great intellectual fortitude and lots of time.> - if you need only fast but no cool features or > journaling, ext2 is still a good choice :)That is however a generally valid conclusion, but with a very, very important qualification: for freshly loaded filesystems. Also with several other important qualifications, but "freshly loaded" is a pet peeve of mine :-).
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
Le Thu, 24 Dec 2009 02:31:10 -0800 (PST) vous écriviez:> - btrfs, ext4 are the overall winners > - xfs to, but creating/deleting many files was *very* slowxfs is slow at file creation/deletion if you mount it with barriers on standard disk drives (not so with hardware RAID controllers). -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <eflorac@intellique.com> | +33 1 78 94 84 02 ------------------------------------------------------------------------ -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Jan 10, 2010 at 08:03:04PM -0500, Casey Allen Shobe wrote:> On Dec 25, 2009, at 11:22 AM, Larry McVoy wrote: >> Dudes, sync() doesn''t flush the fs cache, you have to unmount for >> that. >> Once upon a time Linux had an ioctl() to flush the fs buffers, I used >> it in lmbench. > > > You do not need to unmount - 2.6.16+ have a mechanism in /proc to flush > caches. See http://linux-mm.org/Drop_CachesCool, but I tend to come at problems from a cross platform point of view. Aix no hable /proc :) -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html