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
next prev 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.