From: Peter Nelson <pnelson@andrew.cmu.edu>
To: linux-kernel <linux-kernel@vger.kernel.org>,
ext2-devel@lists.sourceforge.net, ext3-users@redhat.com,
jfs-discussion@oss.software.ibm.com, reiserfs-list@namesys.com,
linux-xfs@oss.sgi.com
Subject: Desktop Filesystem Benchmarks in 2.6.3
Date: Mon, 01 Mar 2004 23:46:21 -0500 [thread overview]
Message-ID: <4044119D.6050502@andrew.cmu.edu> (raw)
I recently decided to reinstall my system and at the same time try a new
file system. Trying to decide what filesystem to use I found a few
benchmarks but either they don't compare all available fs's, are too
synthetic (copy a source tree multiple times or raw i/o), or are meant
for servers/databases (like Bonnie++). The two most file system
intensive tasks I do regularly are `apt-get upgrade` waiting for the
packages to extract and set themselves up and messing around with the
kernel so I benchmarked these. To make it more realistic I installed
ccache and did two compiles, one to fill the cache and a second using
the full cache.
The tests I timed (in order):
* Debootstrap to install base Debian system
* Extract the kernel source
* Run `make all` using the defconfig and an empty ccache
* Copy the entire new directory tree
* Run `make clean`
* Run `make all` again, this time using the filled ccache
* Deleting the entire directory tree
Here is summary of the results based upon what I am calling "dead" time
calculated as `total time - user time`. As you can see in the full
results on my website the user time is almost identical between
filesystems, so I believe this is an accurate comparison. The dead time
is then normalized using ext2 as a baseline (> 1 means it took that many
times longer than ext2).
FS deb tar make cp clean make2 rm total
ext2 1.00 1.00 1.00 1.00 1.00 1.00 1.00 1.00
ext3 1.12 2.47 0.88 1.16 0.91 0.93 3.01 1.13
jfs 1.64 2.18 1.22 1.90 1.60 1.19 12.84 1.79
reiser 1.12 1.99 1.05 1.41 0.92 1.56 1.42 1.28
reiser4 2.69 1.87 1.80 0.63 1.33 2.71 4.14 1.83
xfs 1.06 1.99 0.97 1.67 0.78 1.03 10.27 1.43
Some observations of mine
* Ext2 is still overall the fastest but I think the margin is small
enough that a journal is well worth it
* Ext3, ReiserFS, and XFS all perform similarly and almost up to
Ext2 except:
o XFS takes an abnormally long time to do a large rm even
though it is very fast at a kernel `make clean`
o ReiserFS is significantly slower at the second make (from
ccache)
* JFS is fairly slow overall
* Reiser4 is exceptionally fast at synthetic benchmarks like copying
the system and untaring, but is very slow at the real-world
debootstrap and kernel compiles.
* Though I didn't benchmark it, ReiserFS sometimes takes a second or
two to mount and Reiser4 sometimes takes a second or two to unmount
while all other filesystem's are instantaneous.
Originally I had planned on using Reiser4 because of the glowing reviews
they give themselves but I'm simply not seeing it. It might be that my
Reiser4 is somehow broken but I don't think so. Based on these results I
personally am now going with XFS as it's faster than ReiserFS in the
real-world benchmarks and my current Ext3 partition's performance is
getting worse and worse.
Full benchmark results, system information, and the script I used to run
these tests are available from my website here:
<http://avatar.res.cmu.edu/news/pages/Projects/2.6FileSystemBenchmarks>
Feel free to comment, suggest improvements to my script, or run the test
yourself.
-Peter Nelson
next reply other threads:[~2004-03-02 5:03 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-02 4:46 Peter Nelson [this message]
2004-03-02 7:23 ` Desktop Filesystem Benchmarks in 2.6.3 Hans Reiser
2004-03-02 16:34 ` Peter Nelson
2004-03-02 22:33 ` Dax Kelson
2004-03-02 22:47 ` David Weinehall
2004-03-03 1:30 ` Andrew Ho
2004-03-03 1:41 ` David Weinehall
[not found] ` <20040303014115.GP19111@khan.acc.umu.se.suse.lists.linux.kernel>
2004-03-03 2:39 ` Andi Kleen
2004-03-03 7:47 ` Christoph Hellwig
2004-03-03 8:03 ` Hans Reiser
2004-03-03 8:16 ` Arjan van de Ven
2004-03-03 9:35 ` Hans Reiser
2004-03-03 6:00 ` Robin Rosenberg
2004-03-03 9:43 ` Felipe Alfaro Solana
2004-03-03 9:59 ` Robin Rosenberg
2004-03-03 10:19 ` Felipe Alfaro Solana
2004-03-04 9:28 ` Kristian Köhntopp
2004-03-05 1:59 ` Clemens Schwaighofer
2004-03-03 10:24 ` Mike Gigante
2004-03-03 13:14 ` Felipe Alfaro Solana
2004-03-03 14:16 ` Hans Reiser
2004-03-03 13:42 ` Hans Reiser
2004-03-03 10:13 ` Olaf Frączyk
2004-03-03 13:07 ` Felipe Alfaro Solana
2004-03-04 14:37 ` [Jfs-discussion] " Pascal Gienger
2004-03-04 20:43 ` Per Andreas Buer
2004-03-03 6:30 ` Hans Reiser
2004-03-03 23:41 ` Johannes Stezenbach
2004-03-05 18:46 ` Pavel Machek
2004-03-06 0:16 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2004-03-02 17:11 Ray Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4044119D.6050502@andrew.cmu.edu \
--to=pnelson@andrew.cmu.edu \
--cc=ext2-devel@lists.sourceforge.net \
--cc=ext3-users@redhat.com \
--cc=jfs-discussion@oss.software.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=reiserfs-list@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox