On Sat, Nov 06, 2021 at 09:11:44AM +0800, Qu Wenruo wrote:

On 2021/11/6 04:49, Josef Bacik wrote:

quoted

This code adds the on disk structures for the block group root, which
will hold the block group items for extent tree v2.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
  fs/btrfs/ctree.h                | 26 ++++++++++++++++-
  fs/btrfs/disk-io.c              | 49 ++++++++++++++++++++++++++++-----
  fs/btrfs/disk-io.h              |  2 ++
  fs/btrfs/print-tree.c           |  1 +
  include/trace/events/btrfs.h    |  1 +
  include/uapi/linux/btrfs_tree.h |  3 ++
  6 files changed, 74 insertions(+), 8 deletions(-)

diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 8ec2f068a1c2..b57367141b95 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h

@@ -271,8 +271,13 @@ struct btrfs_super_block {
  	/* the UUID written into btree blocks */
  	u8 metadata_uuid[BTRFS_FSID_SIZE];

+	__le64 block_group_root;
+	__le64 block_group_root_generation;
+	u8 block_group_root_level;
+

Is there any special reason that, block group root can't be put into
root tree?

Yes, I'm so glad you asked!

One of the planned changes with extent-tree-v2 is how we do relocation.  With no
longer being able to track metadata in the extent tree, relocation becomes much
more of a pain in the ass.

In addition, relocation currently has a pretty big problem, it can generate
unlimited delayed refs because it absolutely has to update all paths that point
to a relocated block in a single transaction.

I'm fixing both of these problems with a new relocation thing, which will walk
through a block group, copy those extents to a new block group, and then update
a tree that maps the old logical address to the new logical address.

Because of this we could end up with blocks in the tree root that need to be
remapped from a relocated block group into a new block group.  Thus we need to
be able to know what that mapping is before we go read the tree root.  This
means we have to store the block group root (and the new mapping root I'll
introduce later) in the super block.

These two roots will behave like the chunk root, they'll have to be read first
in order to know where to find any remapped metadata blocks.  Because of that we
have to keep pointers to them in the super block instead of the tree root.

If it's to reduce the unnecessary update on tree root, then I guess free
space tree root should also have some space in super block.

As now free space tree(s) and extent tree(s) are having almost the same
hotness, thus one having direct pointer in super block, while the other
doesn't would not make much sense.

The extent tree and free space trees are both in the tree root, the only thing
that's in the superblock (currently) is the tree root and the chunk root.
Thanks,

Josef