On Tue, Oct 15, 2019 at 08:32:30AM +0800, Qu Wenruo wrote: > > Have we settled the argument whether to use a new tree or key tricks for > > the blocgroup data? I think we have not and will read the previous > > discussions. For a feature like this I want to be sure we understand all > > the pros and cons. > > > Yep, we haven't settled on the whether creating a new tree, or > re-organize the keys. > > But as my last discussion said, I see no obvious pro using the existing > extent tree to hold the new block group item keys, even we can pack them > all together.
For me the obvious pro is minimum change to existing set of trees. > And for backup roots, indeed I forgot to add this feature. > But to me that's a minor point, not a show stopper. > > The most important aspect to me is, to allow real world user of super > large fs to try this feature, to prove the usefulness of this design, > other than my on-paper analyse. > > That's why I'm pushing the patchset, even it may not pass any review. > I just want to hold a up-to-date branch so that when some one needs, it > can grab and try them themselves. Ok that's fine and I can add the branch to for-next for ease of testing. I'm working on a prototype that does it the bg item key way, it compiles and creates almost correct filesystem, so I have to fix it before posting. The patches are on top of your bg-tree feature so we could have both in the same kernel for testing.
