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. > >> 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. To get a real world scenario, I need a file with hundreds GB or even several TB and populate it with a good amount of inline files and enough CoW to fragment the metadata usage. Which I don't have such free space. Anyone who is still struggling with balance + quota, any test data is appreciated. Thanks, Qu
signature.asc
Description: OpenPGP digital signature
