From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>,
Robbie Ko <robbieko@synology.com>,
linux-btrfs@vger.kernel.org, dsterba@suse.cz
Subject: Re: [PATCH] btrfs: speedup mount time with force readahead chunk tree
Date: Mon, 6 Jul 2020 11:37:01 +0300 [thread overview]
Message-ID: <d46206f1-0f6e-1f28-347b-6feb46657e26@suse.com> (raw)
In-Reply-To: <497f7ba0-4efb-b1a2-79a1-62ed2621c743@gmx.com>
On 6.07.20 г. 11:28 ч., Qu Wenruo wrote:
>
>
> On 2020/7/6 下午4:05, Robbie Ko wrote:
>>
>> I've known btrfs_read_block_groups for a long time,
>>
>> we can use BG_TREE freature to speed up btrfs_read_block_groups.
>>
>> https://lwn.net/Articles/801990/
>>
>>
>> But reading the chunk tree also takes some time,
>>
>> we can speed up the chunk tree by using the readahead mechanism.
>>
>> Why we not just use regular forward readahead?
>> - Because the regular forward readahead ,
>> reads only the logical address adjacent to the 64k,
>> but the logical address of the next leaf may not be in 64k.
>
> Great, please add these into the changelog for the need of
> READA_FORWARD_FORCE.
<nod> Performance patches should come with data backing their
performance improvements claims.
>
> But on the other hand, it looks like we could change READA_FORWARD
> without introducing the _FORCE version,
> as _FORCE variant is what we really want.
>
>
> That logical bytenr limit looks not reasonable to me, which makes that
> READA_FORWARD near useless to me.
>
> Although in that direction, we also need to verify all existing
> READA_FORWARD are really correctly.
>
> Personally I tend to prefer change existing READA_FORWARD and review all
> existing callers.
I agree, we should ideally revise the existing READA_FORWARD and give it
better semantics if the current ones are needlessly rigid. Only if this
improves way too cumbersome i.e breaking assumption which are made
should we introduce yet another mode. Because this other mode is really
just special casing and we should avoid special cases as much as possible.
<snip>
next prev parent reply other threads:[~2020-07-06 8:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-01 9:29 [PATCH] btrfs: speedup mount time with force readahead chunk tree robbieko
2020-07-06 6:13 ` Robbie Ko
2020-07-06 6:16 ` Qu Wenruo
2020-07-06 8:05 ` Robbie Ko
2020-07-06 8:28 ` Qu Wenruo
2020-07-06 8:37 ` Nikolay Borisov [this message]
2020-07-06 10:07 ` Robbie Ko
-- strict thread matches above, loose matches on Subject: below --
2020-07-01 9:24 robbieko
2020-07-01 10:58 ` Qu Wenruo
2020-07-01 16:05 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d46206f1-0f6e-1f28-347b-6feb46657e26@suse.com \
--to=nborisov@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=robbieko@synology.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).