All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Holger Hoffstätte" <holger.hoffstaette@googlemail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Performance Issues
Date: Fri, 19 Sep 2014 13:51:22 +0000 (UTC)	[thread overview]
Message-ID: <pan.2014.09.19.13.51.22@googlemail.com> (raw)
In-Reply-To: 1411129114.1811.7.camel@zarniwoop.blob


On Fri, 19 Sep 2014 13:18:34 +0100, Rob Spanton wrote:

> I have a particularly uncomplicated setup (a desktop PC with a hard
> disk) and I'm seeing particularly slow performance from btrfs.  A `git
> status` in the linux source tree takes about 46 seconds after dropping
> caches, whereas on other machines using ext4 this takes about 13s.  My
> mail client (evolution) also seems to perform particularly poorly on
> this setup, and my hunch is that it's spending a lot of time waiting on
> the filesystem.

This is - unfortunately - a particular btrfs oddity/characteristic/flaw,
whatever you want to call it. git relies a lot on fast stat() calls,
and those seem to be particularly slow with btrfs esp. on rotational
media. I have the same problem with rsync on a freshly mounted volume;
it gets fast (quite so!) after the first run.

The simplest thing to fix this is a "du -s >/dev/null" to pre-cache all
file inodes.

I'd also love a technical explanation why this happens and how it could
be fixed. Maybe it's just a consequence of how the metadata tree(s)
are laid out on disk.

> I've tried mounting with noatime, and this has had no effect.  Anyone
> got any ideas?  

Don't drop the caches :-)

-h


  parent reply	other threads:[~2014-09-19 13:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-19 12:18 Performance Issues Rob Spanton
2014-09-19 12:25 ` Swâmi Petaramesh
2014-09-19 12:58   ` Austin S Hemmelgarn
2014-09-19 12:49 ` Austin S Hemmelgarn
2014-09-19 12:59   ` Austin S Hemmelgarn
2014-09-19 13:34 ` Holger Hoffstätte
2014-09-22 11:59   ` David Sterba
2014-09-22 12:37     ` Holger Hoffstätte
2014-09-22 13:25       ` David Sterba
2014-09-19 13:51 ` Holger Hoffstätte [this message]
2014-09-19 14:53   ` Austin S Hemmelgarn
2014-09-19 16:23     ` Holger Hoffstätte
2014-09-19 17:51   ` Zach Brown
2014-09-20  8:23   ` Marc Dietrich
2014-09-20 13:41     ` Martin
2014-09-20 18:29       ` Chris Murphy
2014-09-20 14:04     ` Wang Shilong
2014-09-20 20:44       ` Marc Dietrich
2014-09-19 15:05 ` Josef Bacik
2014-09-19 16:51   ` Rob Spanton
2014-09-19 17:45     ` Josef Bacik
2014-10-30 14:23       ` Rob Spanton
2014-09-20  5:58     ` Duncan
     [not found] <CAEsGcVufqGYA3OMBUPnTBuXc0UxrrjJdFEr8kQXkLWbTcvd6Gw@mail.gmail.com>
2012-10-06 16:49 ` performance issues corn chips
2012-10-06 16:50   ` Joao Eduardo Luis
  -- strict thread matches above, loose matches on Subject: below --
2005-09-15 13:02 Performance issues tmp123
2005-09-14 19:53 Ferry van Aesch
2005-09-15 12:43 ` TheGesus
2005-09-15 12:53 ` lst_hoe01

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=pan.2014.09.19.13.51.22@googlemail.com \
    --to=holger.hoffstaette@googlemail.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.