On 2014-09-19 09:51, 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.
I find that kind of funny, because regardless of filesystem, stat() is 
one of the *slowest* syscalls on almost every *nix system in existence.
>
> 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.
While I don't know for certain, I think it's largely just a side effect 
of the lack of performance tuning in the BTRFS code.
>
>> I've tried mounting with noatime, and this has had no effect.  Anyone
>> got any ideas?
>
> Don't drop the caches :-)
>
> -h