On Thu, Sep 06, 2018 at 09:41:14AM +0800, Qu Wenruo wrote: > > > On 2018/9/5 下午9:11, David Sterba wrote: > > On Wed, Sep 05, 2018 at 01:03:39PM +0800, Qu Wenruo wrote: > >> Tree reloc tree doesn't contribute to qgroup numbers, as we have > > > > I think you can call it just 'reloc tree', I'm fixing that in all > > changelogs and comments anyway. > > But there is another tree called data reloc tree. > That why I'm sticking to tree reloc tree to distinguish from data reloc > tree.
So call it 'reloc tree' and 'data reloc tree', the naming of BTRFS_TREE_RELOC_OBJECTID does not follow the other tree naming and I don't know if the inention was to name it after the 'tree log' scheme or the 'extent tree'. Or if there was an intention behind the naming at all. If this is going to bother us too much, I won't mind renaming it to BTRFS_RELOC_TREE_OBJECTID everywhere. For consistency. > >> accounted them at balance time (check replace_path()). > >> > >> Skip such unneeded subtree trace should reduce some performance > >> overhead. > > > > Please provide some numbers or description of the improvement. There are > > several performance problems caused by qgroups so it would be good to > > get a better idea how much this patch is going to help. Thanks. > > That's the problem. > For my internal test, with 3000+ tree blocks, metadata balance could > save about 1~2%. > But according to dump-tree, the tree layout is almost the worst case > scenario, just one metadata block group owns all the tree blocks. If you do such test, it's also a good example for the changelog. It describes the worst case and this information can be used to prepare testing environment on large data samples.
