Re: [PATCH v2] btrfs: speedup mount time with readahead chunk tree

[David Sterba <dsterba@suse.cz>]

On Tue, Jul 07, 2020 at 11:59:44AM +0800, robbieko wrote:
> From: Robbie Ko <robbieko@synology.com>
> 
> When mounting, we always need to read the whole chunk tree,
> when there are too many chunk items, most of the time is
> spent on btrfs_read_chunk_tree, because we only read one
> leaf at a time.
> 
> It is unreasonable to limit the readahead mechanism to a
> range of 64k, so we have removed that limit.
> 
> In addition we added reada_maximum_size to customize the
> size of the pre-reader, The default is 64k to maintain the
> original behavior.
> 
> So we fix this by used readahead mechanism, and set readahead
> max size to ULLONG_MAX which reads all the leaves after the
> key in the node when reading a level 1 node.

The readahead of chunk tree is a special case as we know we will need
the whole tree, in all other cases the search readahead needs is
supposed to read only one leaf.

For that reason I don't want to touch the current path readahead logic
at all and do the chunk tree readahead in one go instead of the
per-search.

Also I don't like to see size increase of btrfs_path just to use the
custom once.

The idea of the whole tree readahead is to do something like:

- find first item
- start readahead on all leaves from its level 1 node parent
  (readahead_tree_block)
- when the level 1 parent changes during iterating items, start the
  readahead again

This skips readahead of all nodes above level 1, if you find a nicer way
to readahead the whole tree I won't object, but for the first
implementation the level 1 seems ok to me.

> I have a test environment as follows:
> 
> 200TB btrfs volume: used 192TB
> 
> Data, single: total=192.00TiB, used=192.00TiB
> System, DUP: total=40.00MiB, used=19.91MiB

Can you please check what's the chunk tree height? 'btrfs inspect
tree-stats' prints that but it takes long as needs to go through the
whole metadata, so extracting it from 'btrfs inspect dump-tree -c chunk'
would be faster. Thanks.