linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: tytso@mit.edu
To: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Peter Grandi <pg_jf2@jf2.for.sabi.co.UK>,
	xfs@oss.sgi.com, reiserfs-devel@vger.kernel.org,
	linux-ext4@vger.kernel.org, linux-btrfs@vger.kernel.org,
	jfs-discussion@lists.sourceforge.net,
	ext-users <ext3-users@redhat.com>,
	linux-nilfs@vger.kernel.org
Subject: Re: [Jfs-discussion] benchmark results
Date: Fri, 25 Dec 2009 11:11:46 -0500	[thread overview]
Message-ID: <20091225161146.GC32757@thunk.org> (raw)
In-Reply-To: <20091224234631.GA1028@ioremap.net>

On Fri, Dec 25, 2009 at 02:46:31AM +0300, Evgeniy Polyakov wrote:
> > [1] http://samba.org/ftp/tridge/dbench/README
> 
> Was not able to resist to write a small notice, what no matter what, but
> whatever benchmark is running, it _does_ show system behaviour in one
> or another condition. And when system behaves rather badly, it is quite
> a common comment, that benchmark was useless. But it did show that
> system has a problem, even if rarely triggered one :)

If people are using benchmarks to improve file system, and a benchmark
shows a problem, then trying to remedy the performance issue is a good
thing to do, of course.  Sometimes, though the case which is
demonstrated by a poor benchmark is an extremely rare corner case that
doesn't accurately reflect common real-life workloads --- and if
addressing it results in a tradeoff which degrades much more common
real-life situations, then that would be a bad thing.

In situations where benchmarks are used competitively, it's rare that
it's actually a *problem*.  Instead it's much more common that a
developer is trying to prove that their file system is *better* to
gullible users who think that a single one-dimentional number is
enough for them to chose file system X over file system Y.

For example, if I wanted to play that game and tell people that ext4
is better, I'd might pick this graph:

http://btrfs.boxacle.net/repository/single-disk/2.6.29-rc2/2.6.29-rc2/2.6.29-rc2_Mail_server_simulation._num_threads=32.html

On the other hand, this one shows ext4 as the worst compared to all
other file systems:

http://btrfs.boxacle.net/repository/single-disk/2.6.29-rc2/2.6.29-rc2/2.6.29-rc2_Large_file_random_writes_odirect._num_threads=8.html

Benchmarking, like statistics, can be extremely deceptive, and if
people do things like carefully order a tar file so the files are
optimal for a file system, it's fair to ask whether that's a common
thing for people to be doing (either unpacking tarballs or unpacking
tarballs whose files have been carefully ordered for a particular file
systems).  When it's the only number used by a file system developer
when trying to convince users they should use their file system, at
least in my humble opinion it becomes murderously dishonest.

						- Ted

  reply	other threads:[~2009-12-25 16:11 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 [this message]
2010-01-04 16:27         ` Chris Mason
2010-01-04 18:57           ` Michael Rubin
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=20091225161146.GC32757@thunk.org \
    --to=tytso@mit.edu \
    --cc=ext3-users@redhat.com \
    --cc=jfs-discussion@lists.sourceforge.net \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=pg_jf2@jf2.for.sabi.co.UK \
    --cc=reiserfs-devel@vger.kernel.org \
    --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).