Re: btrfs mount takes too long time

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

On 2021/9/2 上午12:11, Dāvis Mosāns wrote:
> pirmd., 2021. g. 30. aug., plkst. 16:08 — lietotājs Anand Jain
> (<anand.jain@oracle.com>) rakstīja:
>>
>> open_ctree() took 228254398 us. And 98% of it that is 225418272 us
>> was taken by btrfs_read_block_groups().
>>
>> -------------------
>>    1) $ 225418272 us | } /* btrfs_read_block_groups [btrfs] */

As long as it's not zoned device, this is a known problem.

Block group items by its original design is scattered across the huge
extent tree.

Grabbing them all needs quite a lot of random IO, for large fs it's very
time consuming.

I have purposed a skinny bg tree design to put all block group items
into one tree, so that would greatly speed up the whole mount process.
And with user-space tool to do the convert.

But recently Josef is developing a completely new extent tree design,
which will include a similar design for it.

For know I'm not sure what's the way to go, either we can wait for
extent-tree-v2, or should we push for the middle ground skinny bg tree?

David, Any idea on this?

Thanks,
Qu
>>    1) * 16934.96 us | btrfs_check_rw_degradable [btrfs]();
>>    0) 0.967 us | btrfs_apply_pending_changes [btrfs]();
>>    0) 0.239 us | btrfs_read_qgroup_config [btrfs]();
>>    0) * 21017.34 us | btrfs_get_root_ref [btrfs]();
>>    0) + 15.717 us | btrfs_start_pre_rw_mount [btrfs]();
>>    0) 0.865 us | btrfs_discard_resume [btrfs]();
>>    0) $ 228254398 us | } /* open_ctree [btrfs] */
>> -------------------
>>
>> Now we need to run the same thing on btrfs_read_block_groups(),
>> could you please run.. [1] (no need of the time).
>>
>> [1]
>>     $ umount /btrfs;
>>     $./ftracegraph btrfs_read_block_groups 2 "*:mod:btrfs" "mount
>> /dev/vg/scratch0 /btrfs"
>>
>> Thanks, Anand
>>
>>
>
> Hi,
>
> I also have a btrfs filesystem that takes a while to mount.
> So I'm interested if this could be improved.
>
> $ ./ftracegraph open_ctree 2 "*:mod:btrfs" "time mount /dev/md127 -o
> space_cache=v2,compress=zstd,acl,subvol=Data /mnt/Data/"
> kernel.ftrace_enabled = 1
>
> real    1m33,638s
> user    0m0,000s
> sys     0m1,130s
>
> Here's the trace output https://dāvis.lv/files/ftracegraph.out.gz
>
> The filesystem is on top of RAID6 mdadm array which is from 9x 3TB HDDs.
>
> Best regards,
> Dāvis
>