Re: [PATCH v2 0/3] btrfs: separate BLOCK_GROUP_TREE feature from extent-tree-v2

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

On 2022/7/27 06:09, Qu Wenruo wrote:
>
>
> On 2022/7/27 05:52, David Sterba wrote:
>> On Wed, Jul 27, 2022 at 05:47:25AM +0800, Qu Wenruo wrote:
>>>
>>>
>>> On 2022/7/27 01:59, David Sterba wrote:
>>>> On Wed, Jul 20, 2022 at 01:06:58PM +0800, Qu Wenruo wrote:
>>>>> Qu Wenruo (3):
>>>>>     btrfs: enhance unsupported compat RO flags handling
>>>>>     btrfs: don't save block group root into super block
>>>>>     btrfs: separate BLOCK_GROUP_TREE compat RO flag from
>>>>> EXTENT_TREE_V2
>>>>
>>>> It's short series and I don't see any new code to use the separate tree
>>>> for bg items, so it's on top of the extent tree v2, right?
>>>
>>> Yes, it's based on extent tree v2 prepare code that is already in the
>>> mainline code.
>>>
>>>>
>>>>   From the last time we were experimenting with the block group tree, I
>>>> was trying to avoid a new tree but there were problems. So, I think we
>>>> can go with the separate tree that you suggest. We have reports about
>>>> slow mount and people use large filesystems, so this is justified.
>>>>
>>>> Will it be possible to convert existing filesystem to use the bg tree?
>>>
>>> Yes, that's completely planned as the old bg tree code, btrfs-progs
>>> convert tool will be provided (mostly in btrfstune).
>>
>> Ok, good. I'm thinking if we should go for an online conversion too or
>> not, because on a many-TB filesystem it would possibly take a long time
>> but the benefit is not to unmount and do the conversion.
>
> For my previous tests, even TB level (used space) fs, it only takes
> seconds to do the convert (although on SSD).
>
> For HDD systems, it would be as slow as the mount time for the convert.
> Most of time spent would be just searching the block group items,
> writing them into bg tree would be super fast though.

Despite the incoming multi-transaction bg tree convert tool
(bidirectional), mind me to update the kernel series to address one of
the concern from Josef?

To reduce the test matrix, I'd like to make bg tree to rely on free
space tree and no holes features.

Although those features have no linkage to each other, such artificial
requirement should greatly reduce our test combinations.

Thanks,
Qu
>
> Currently I'm working on a multi-transaction solution in btrfstune to be
> extra safe on the convert.
> (Previous code is one transaction to do the convert, which may or may
> not handle thousands of bg items).
>
>>
>> We could copy what the free space conversion does on remount, for bg
>> tree implemented as "set some flag via sysfs" and ten trigger remount
>> that does all th work. It should be less or comparable work to free
>> space tree conversion, it's basically copying the block group items to
>> the new tree and deleting from extent tree.
>
> I tend not to do any convert in kernel even it may not be that complex.
>
> Shouldn't we keep the kernel code small and put the convert thing all
> into progs?
>
> Thanks,
> Qu