From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Filipe Manana <fdmanana@kernel.org>, Johannes Thumshirn <jth@kernel.org>
Cc: Chris Mason <clm@fb.com>, Josef Bacik <josef@toxicpanda.com>,
David Sterba <dsterba@suse.com>,
"open list:BTRFS FILE SYSTEM" <linux-btrfs@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
Qu Wenruo <wqu@suse.com>
Subject: Re: [PATCH v2] btrfs: reduce chunk_map lookups in btrfs_map_block
Date: Tue, 13 Aug 2024 11:04:52 +0000 [thread overview]
Message-ID: <603670e6-e0c6-4f54-be6d-272042861bce@wdc.com> (raw)
In-Reply-To: <CAL3q7H5jwR75FwT213yteX5m=5G8ehKmnKxv=xYXbY+UuhP+qQ@mail.gmail.com>
On 13.08.24 12:57, Filipe Manana wrote:
> On Tue, Aug 13, 2024 at 11:49 AM Johannes Thumshirn <jth@kernel.org> wrote:
>>
>> From: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>>
>> Currently we're calling btrfs_num_copies() before btrfs_get_chunk_map() in
>> btrfs_map_block(). But btrfs_num_copies() itself does a chunk map lookup
>> to be able to calculate the number of copies.
>>
>> So split out the code getting the number of copies from btrfs_num_copies()
>> into a helper called btrfs_chunk_map_num_copies() and directly call it
>> from btrfs_map_block() and btrfs_num_copies().
>>
>> This saves us one rbtree lookup per btrfs_map_block() invocation.
>>
>> Reviewed-by: Qu Wenruo <wqu@suse.com>
>> Reviewed-by: Filipe Manana <fdmanana@suse.com>
>> Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
>> ---
>> Changes in v2:
>> - Added Reviewed-bys
>> - Reflowed comments
>> - Moved non RAID56 cases to the end without an if
>> Link to v1:
>> https://lore.kernel.org/all/20240812165931.9106-1-jth@kernel.org/
>>
>> fs/btrfs/volumes.c | 58 +++++++++++++++++++++++++---------------------
>> 1 file changed, 32 insertions(+), 26 deletions(-)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index e07452207426..796f6350a017 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -5781,38 +5781,44 @@ void btrfs_mapping_tree_free(struct btrfs_fs_info *fs_info)
>> write_unlock(&fs_info->mapping_tree_lock);
>> }
>>
>> +static int btrfs_chunk_map_num_copies(struct btrfs_chunk_map *map)
>
> Same as commented before, can be const.
No it can't:
fs/btrfs/volumes.c:5784:8: warning: type qualifiers ignored on function
return type [-Wignored-qualifiers]
5784 | static const int btrfs_chunk_map_num_copies(struct
btrfs_chunk_map *map)
Or did you mean the const struct btrfs_chunk_map? That could be done but
I don't see a reason.
>
>> +{
>> + enum btrfs_raid_types index = btrfs_bg_flags_to_raid_index(map->type);
>> +
>> + if (map->type & BTRFS_BLOCK_GROUP_RAID5)
>> + return 2;
>> +
>> + /*
>> + * There could be two corrupted data stripes, we need to loop
>> + * retry in order to rebuild the correct data.
>> + *
>> + * Fail a stripe at a time on every retry except the stripe
>> + * under reconstruction.
>> + */
>> + if (map->type & BTRFS_BLOCK_GROUP_RAID6)
>> + return map->num_stripes;
>> +
>> + /* Non-RAID56, use their ncopies from btrfs_raid_array. */
>> + return btrfs_raid_array[index].ncopies;
>> +}
>> +
>> int btrfs_num_copies(struct btrfs_fs_info *fs_info, u64 logical, u64 len)
>> {
>> struct btrfs_chunk_map *map;
>> - enum btrfs_raid_types index;
>> - int ret = 1;
>> + int ret;
>>
>> map = btrfs_get_chunk_map(fs_info, logical, len);
>> if (IS_ERR(map))
>> /*
>> - * We could return errors for these cases, but that could get
>> - * ugly and we'd probably do the same thing which is just not do
>> - * anything else and exit, so return 1 so the callers don't try
>> - * to use other copies.
>> + * We could return errors for these cases, but that
>> + * could get ugly and we'd probably do the same thing
>> + * which is just not do anything else and exit, so
>> + * return 1 so the callers don't try to use other
>> + * copies.
>
> My previous comment about reformatting was just for the comment that
> was moved, the one now inside btrfs_chunk_map_num_copies().
> For this one I don't think we should do it, as we aren't moving it
> around or changing its content.
>
> It's just confusing to have this sort of unrelated change mixed in.
>
Whoops that was fat fingered somehow.
next prev parent reply other threads:[~2024-08-13 11:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 10:49 Johannes Thumshirn
2024-08-13 10:56 ` Filipe Manana
2024-08-13 11:04 ` Johannes Thumshirn [this message]
2024-08-13 11:07 ` Filipe Manana
2024-08-13 12:47 ` 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=603670e6-e0c6-4f54-be6d-272042861bce@wdc.com \
--to=johannes.thumshirn@wdc.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=fdmanana@kernel.org \
--cc=josef@toxicpanda.com \
--cc=jth@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wqu@suse.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
all inboxes | Powered by JetHome®