Re: Performance Issues

[Zach Brown <zab@zabbo.net>]

On Fri, Sep 19, 2014 at 01:51:22PM +0000, Holger Hoffstätte wrote:
> 
> 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.

There's a lot of meat behind that "just a consequence" but, yes, that's
the heart of it.  Different metadata designs result in different io
patterns which single rotating drives are exquisitely sensitive to.

You can look for differences in io patterns with iostat, blktrace,
iowatcher, etc.  They'll show differences in io sizes, concurrency,
locality, and often differences in the amount of blocks of data read.

  http://masoncoding.com/iowatcher/

As for "fixing it", welllll, it's arguably working as intended.  If you
turned btrfs from one cow tree into lots of journaled trees of trees
then, well, we'd be left with an absurd reimplementation of ext*|xfs.

- z