Re: [RFC ONLY 3/8] btrfs: read raid-stripe-tree from disk

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/5/17 16:13, Johannes Thumshirn wrote:
> On 17/05/2022 10:10, Qu Wenruo wrote:
>>
>>
>> On 2022/5/16 22:31, Johannes Thumshirn wrote:
>>> If we're discovering a raid-stripe-tree on mount, read it from disk.
>>>
>>> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>>> ---
>>>    fs/btrfs/ctree.h           |  1 +
>>>    fs/btrfs/disk-io.c         | 12 ++++++++++++
>>>    include/uapi/linux/btrfs.h |  1 +
>>>    3 files changed, 14 insertions(+)
>>>
>>> diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
>>> index 20aa2ebac7cd..1db669662f61 100644
>>> --- a/fs/btrfs/ctree.h
>>> +++ b/fs/btrfs/ctree.h
>>> @@ -667,6 +667,7 @@ struct btrfs_fs_info {
>>>    	struct btrfs_root *uuid_root;
>>>    	struct btrfs_root *data_reloc_root;
>>>    	struct btrfs_root *block_group_root;
>>> +	struct btrfs_root *stripe_root;
>>>
>>>    	/* the log root tree is a directory of all the other log roots */
>>>    	struct btrfs_root *log_root_tree;
>>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>>> index d456f426924c..c0f08917465a 100644
>>> --- a/fs/btrfs/disk-io.c
>>> +++ b/fs/btrfs/disk-io.c
>>> @@ -1706,6 +1706,9 @@ static struct btrfs_root *btrfs_get_global_root(struct btrfs_fs_info *fs_info,
>>>
>>>    		return btrfs_grab_root(root) ? root : ERR_PTR(-ENOENT);
>>>    	}
>>> +	if (objectid == BTRFS_RAID_STRIPE_TREE_OBJECTID)
>>> +		return btrfs_grab_root(fs_info->stripe_root) ?
>>> +			fs_info->stripe_root : ERR_PTR(-ENOENT);
>>>    	return NULL;
>>>    }
>>>
>>> @@ -1784,6 +1787,7 @@ void btrfs_free_fs_info(struct btrfs_fs_info *fs_info)
>>>    	btrfs_put_root(fs_info->fs_root);
>>>    	btrfs_put_root(fs_info->data_reloc_root);
>>>    	btrfs_put_root(fs_info->block_group_root);
>>> +	btrfs_put_root(fs_info->stripe_root);
>>>    	btrfs_check_leaked_roots(fs_info);
>>>    	btrfs_extent_buffer_leak_debug_check(fs_info);
>>>    	kfree(fs_info->super_copy);
>>> @@ -2337,6 +2341,7 @@ static void free_root_pointers(struct btrfs_fs_info *info, bool free_chunk_root)
>>>    	free_root_extent_buffers(info->fs_root);
>>>    	free_root_extent_buffers(info->data_reloc_root);
>>>    	free_root_extent_buffers(info->block_group_root);
>>> +	free_root_extent_buffers(info->stripe_root);
>>>    	if (free_chunk_root)
>>>    		free_root_extent_buffers(info->chunk_root);
>>>    }
>>> @@ -2773,6 +2778,13 @@ static int btrfs_read_roots(struct btrfs_fs_info *fs_info)
>>>    		fs_info->uuid_root = root;
>>>    	}
>>>
>>
>> I guess in the real patch, we need to check the incompatble feature first.
>
> Or at least a compatible_ro. For regular drives it should be sufficient, for
> zoned drives mounting with raid without a stripe tree will fail.
>
>>
>> Another problem is, how do we do bootstrap?
>>
>> If our metadata (especially chunk tree) is also in some chunks which is
>> stripe-tree mapped, without stripe tree we're even unable to read the
>> chunk tree.
>>
>> Or do you plan to not support metadata on stripe-tree mapped chunks?
>
> I do, but I have no clue yet how to attack this problem. I was hoping to get some
> insights from Josef's extent-tree v2 series.

Personally speaking, a per-chunk flag/type allowing us to know if a
chunk has stripe mapped is much better for testing, and can bring you
much needed time for further improvement.

>
> Metadata on the stripe tree really is the main blocker right now.

That's no doubt.

Thanks,
Qu