All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: debian developer <debiandev@gmail.com>
Cc: Steven Pratt <slpratt@austin.ibm.com>, linux-btrfs@vger.kernel.org
Subject: Re: More performance results
Date: Tue, 03 Feb 2009 10:01:36 -0500	[thread overview]
Message-ID: <1233673296.7246.4.camel@think.oraclecorp.com> (raw)
In-Reply-To: <f24d23310902030532w6cad0b6v209951bb24fba388@mail.gmail.com>

On Tue, 2009-02-03 at 19:02 +0530, debian developer wrote:
> On Mon, Feb 2, 2009 at 9:28 PM, Steven Pratt <slpratt@austin.ibm.com> wrote:
> >
> > Finally cleared out a backlog of results to upload.  Main performance page is updated with all the links.  (http://btrfs.boxacle.net/)  Most recent results are on 2.6.29-rc2. As usual see analysis directory of results for oprofile, including call graphs.
> >
> > Single disk results are not too bad.  Raid still falls apart on any write heavy workload.
> 
> Would you please mind explaining how bad the results are and
> how much more this needs to be improved for Btrfs to be perfomance
> wise acceptable?
> 
> I see that Btrfs almost everywhere lacks XFS and others in some cases.

These benchmarks are great because they hammer on some of the worst
cases code in btrfs.  The mail-server benchmark for example isn't quite
a mail server workload because it doesn't fsync the files to disk.

But what it does do is hammer on a mixed file read/write/delete
workload, which hits btree concurrency and file layout.  In my testing
here, the big difference between ext4 and btrfs isn't writing to files,
it is actually the unlinks.  If I take them out of the run, btrfs is
very close to ext4 times.

So, I'm working on that.

The random write workload is probably just a file allocation problem.
Btrfs should be perform very well in that workload.

-chris





  parent reply	other threads:[~2009-02-03 15:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-02 15:58 More performance results Steven Pratt
2009-02-02 16:00 ` Chris Mason
2009-02-02 17:35   ` Steven Pratt
2009-02-03 13:32 ` debian developer
2009-02-03 14:22   ` jim owens
2009-02-03 14:56   ` Steven Pratt
2009-02-03 15:01   ` Chris Mason [this message]
2009-02-03 15:13     ` Steven Pratt
2009-02-03 16:38       ` Chris Mason
2009-02-04  2:57     ` Bron Gondwana
2009-03-16 17:06 ` Mingming Cao
2009-03-16 17:06   ` Mingming Cao
  -- strict thread matches above, loose matches on Subject: below --
2008-12-16 15:44 Steven Pratt

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=1233673296.7246.4.camel@think.oraclecorp.com \
    --to=chris.mason@oracle.com \
    --cc=debiandev@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=slpratt@austin.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.