linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: "K. Richard Pixley" <rich@noir.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Confused by performance
Date: Thu, 17 Jun 2010 05:57:25 -0400	[thread overview]
Message-ID: <20100617095725.GM27466@think> (raw)
In-Reply-To: <4C191330.5060905@noir.com>

On Wed, Jun 16, 2010 at 11:08:48AM -0700, K. Richard Pixley wrote:
> Once again I'm stumped by some performance numbers and hoping for
> some insight.
> 
> Using an 8-core server, building in parallel, I'm building some
> code.  Using ext2 over a 5-way, (5 disk), lvm partition, I can build
> that code in 35 minutes.  Tests with dd on the raw disk and lvm
> partitions show me that I'm getting near linear improvement from the
> raw stripe, even with dd runs exceeding 10G, so I think that
> convinces me that my disks and controller subsystem are capable of
> operating in parallel and in concert.  hdparm -t numbers seem to
> support what I'm seeing from dd.
> 
> Running the same build, same parallelism, over a btrfs (defaults)
> partition on a single drive, I'm seeing very consistent build times
> around an hour, which is reasonable.  I get a little under an hour
> on ext4 single disk, again, very consistently.
> 
> However, if I build a btrfs file system across the 5 disks, my build
> times decline to around 1.5 - 2hrs, although there's about a 30min
> variation between different runs.
> 
> If I build a btrfs file system across the 5-way lvm stripe, I get
> even worse performance at around 2.5hrs per build, with about a
> 45min variation between runs.
> 
> I can't explain these last two results.  Any theories?

I suspect they come down to different raid levels done by btrfs, and
maybe barriers.

By default btrfs will duplicate metadata, so ext2 is doing much less
metadata IO than btrfs does.

Try mkfs.btrfs -m raid0 -d raid0 /dev/xxx /dev/xxy ...

Then try mount -o nobarrier /dev/xxx /mnt

Someone else mentioned blktrace, it would help explain things if you're
interested in tracking this down.

-chris


      parent reply	other threads:[~2010-06-17  9:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-24 21:08 Confused by performance K. Richard Pixley
2010-05-25  3:59 ` Mike Fedyk
2010-05-28  1:45 ` K. Richard Pixley
2010-06-16 18:08   ` K. Richard Pixley
2010-06-16 19:21     ` Roberto Ragusa
     [not found]       ` <AANLkTinM6ab_KEynfgvVT9v5TmcogoLZ0PLAz2oPnsiS@mail.gmail.com>
2010-06-16 19:35         ` Freddie Cash
2010-06-16 19:56           ` Roberto Ragusa
2010-06-17  6:57           ` David Brown
2010-06-16 21:44     ` Daniel J Blueman
2010-06-17  9:57     ` Chris Mason [this message]

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=20100617095725.GM27466@think \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rich@noir.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;
as well as URLs for NNTP newsgroup(s).