Re: Performance Issues

[David Sterba <dsterba@suse.cz>]

On Fri, Sep 19, 2014 at 01:34:38PM +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
> 
> 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.

The stat() call is the most severe slowdown factor in combination with
fragmentation and random order of the inodes that are being stat()ed.

A 'ls -f' (that does not stat) goes only through the DIR_INDEX_KEY items
in the b-tree that are usually packed together and reading is sequential
and fast.

A 'ls' that calls stat() in turn will have to seek for the INODE_ITEM
item that can be far from all the currently read metadata blocks.

What could help here is a directory readahead, pre-read the inode items
during the readdir() call. I tried this with current readahead (some
timeago) code but this didn't lead to improvement. The reason is that
the readahead has low priority and is not able to cache the metadata
blocks in time.

So the fix or rather workaround is to implement high priority readahead
and trigger it for all DIR_INDEX keys that get returned by readdir().
This will hurt the 'ls -f' usecase.

In your example, 'du -s' acts as the readahead step.