From: Michael Rubin <mrubin@google.com>
To: Chris Mason <chris.mason@oracle.com>,
tytso@mit.edu, Evgeniy Polyakov <zbr@ioremap.net>,
Peter Grandi <pg_jf2@jf2.for.sabi.co.uk>,
xfs@oss.sgi.com, reiserfs-devel@vger.kernel.org, lin
Subject: Re: [Jfs-discussion] benchmark results
Date: Mon, 4 Jan 2010 10:57:49 -0800 [thread overview]
Message-ID: <532480951001041057w3ad8d1dfy361ced0346ebaaa4__35393.752976279$1262631524$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <20100104162748.GA11932@think>
Google is currently in the middle of upgrading from ext2 to a more up
to date file system. We ended up choosing ext4. This thread touches
upon many of the issues we wrestled with, so I thought it would be
interesting to share. We should be sending out more details soon.
The driving performance reason to upgrade is that while ext2 had been "good
enough" for a very long time the metadata arrangement on a stale file
system was leading to what we call "read inflation". This is where we
end up doing many seeks to read one block of data. In general latency
from poor block allocation was causing performance hiccups.
We spent a lot of time with unix standard benchmarks (dbench, compile
bench, et al) on xfs, ext4, jfs to try to see which one was going to
perform the best. In the end we mostly ended up using the benchmarks
to validate our assumptions and do functional testing. Larry is
completely right IMHO. These benchmarks were instrumental in helping
us understand how the file systems worked in controlled situations and
gain confidence from our customers.
For our workloads we saw ext4 and xfs as "close enough" in performance
in the areas we cared about. The fact that we had a much smoother
upgrade path with ext4 clinched the deal. The only upgrade option we
have is online. ext4 is already moving the bottleneck away from the
storage stack for some of our most intensive applications.
It was not until we moved from benchmarks to customer workload that we
were able to make detailed performance comparisons and find bugs in
our implementation.
"Iterate often" seems to be the winning strategy for SW dev. But when
it involves rebooting a cloud of systems and making a one way
conversion of their data it can get messy. That said I see benchmarks
as tools to build confidence before running traffic on redundant live
systems.
mrubin
PS for some reason "dbench" holds mythical power over many folks I
have met. They just believe it's the most trusted and standard
benchmark for file systems. In my experience it often acts as a random
number generator. It has found some bugs in our code as it exercises
the VFS layer very well.
next prev parent reply other threads:[~2010-01-04 18:58 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-24 10:31 benchmark results Christian Kujau
2009-12-24 12:06 ` Ryusuke Konishi
2009-12-24 12:59 ` Teran McKinney
2009-12-24 20:01 ` Christian Kujau
2009-12-24 13:05 ` Peter Grandi
2009-12-24 21:27 ` [Jfs-discussion] " tytso
2009-12-24 23:46 ` Evgeniy Polyakov
2009-12-25 16:11 ` tytso
2010-01-04 16:27 ` Chris Mason
2010-01-04 18:57 ` Michael Rubin [this message]
2010-01-05 0:41 ` Dave Chinner
2010-01-05 15:31 ` Steven Pratt
2009-12-25 1:52 ` Christian Kujau
2009-12-25 13:19 ` lakshmi pathi
2009-12-25 16:14 ` tytso
2009-12-25 16:22 ` Larry McVoy
2009-12-25 16:33 ` tytso
2009-12-25 18:51 ` Christian Kujau
2009-12-26 16:00 ` jim owens
2009-12-26 19:06 ` Christian Kujau
2009-12-27 19:50 ` jim owens
2009-12-27 21:55 ` Christian Kujau
2009-12-27 22:33 ` tytso
2009-12-28 1:24 ` Christian Kujau
2009-12-28 14:08 ` Larry McVoy
2010-01-15 21:42 ` Edward Shishkin
2009-12-26 19:19 ` tytso
[not found] ` <20091225163341.GE32757@thunk.org>
2009-12-25 18:56 ` Christian Kujau
2009-12-25 19:32 ` Christian Kujau
2010-01-11 1:03 ` Casey Allen Shobe
2010-01-11 1:32 ` Larry McVoy
2009-12-25 18:42 ` Christian Kujau
2009-12-29 11:27 ` Emmanuel Florac
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='532480951001041057w3ad8d1dfy361ced0346ebaaa4__35393.752976279$1262631524$gmane$org@mail.gmail.com' \
--to=mrubin@google.com \
--cc=chris.mason@oracle.com \
--cc=pg_jf2@jf2.for.sabi.co.uk \
--cc=reiserfs-devel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xfs@oss.sgi.com \
--cc=zbr@ioremap.net \
/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;
as well as URLs for NNTP newsgroup(s).