From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 4/7] btrfs: scrub: remove unnecessary dev/physical lookup for scrub_stripe_report_errors()
Date: Tue, 19 Mar 2024 06:23:08 +1030 [thread overview]
Message-ID: <9fca4194-01cf-4b73-80e1-e1a55dd8c825@gmx.com> (raw)
In-Reply-To: <CAL3q7H67XsqdDXAS57r8i8QZZsSVoMsEZZjGSeY=si7GNbiM1A@mail.gmail.com>
在 2024/3/19 02:46, Filipe Manana 写道:
> On Thu, Mar 14, 2024 at 8:28 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 在 2024/3/15 03:56, Filipe Manana 写道:
>>> On Thu, Mar 14, 2024 at 9:50 AM Qu Wenruo <wqu@suse.com> wrote:
>>>>
>>>> The @stripe passed into scrub_stripe_report_errors() either has
>>>> stripe->dev and stripe->physical properly populated (regular data
>>>> stripes) or stripe->flags would have SCRUB_STRIPE_FLAG_NO_REPORT
>>>> (RAID56 P/Q stripes).
>>>>
>>>> Thus there is no need to go with btrfs_map_block() to get the
>>>> dev/physical.
>>>>
>>>> Just add an extra ASSERT() to make sure we get stripe->dev populated
>>>> correctly.
>>>>
>>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>>> ---
>>>> fs/btrfs/scrub.c | 59 ++++++------------------------------------------
>>>> 1 file changed, 7 insertions(+), 52 deletions(-)
>>>>
>>>> diff --git a/fs/btrfs/scrub.c b/fs/btrfs/scrub.c
>>>> index 5e371ffdb37b..277583464371 100644
>>>> --- a/fs/btrfs/scrub.c
>>>> +++ b/fs/btrfs/scrub.c
>>>> @@ -860,10 +860,8 @@ static void scrub_stripe_submit_repair_read(struct scrub_stripe *stripe,
>>>> static void scrub_stripe_report_errors(struct scrub_ctx *sctx,
>>>> struct scrub_stripe *stripe)
>>>> {
>>>> - static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
>>>> - DEFAULT_RATELIMIT_BURST);
>>>> struct btrfs_fs_info *fs_info = sctx->fs_info;
>>>> - struct btrfs_device *dev = NULL;
>>>> + struct btrfs_device *dev = stripe->dev;
>>>> u64 stripe_physical = stripe->physical;
>>>> int nr_data_sectors = 0;
>>>> int nr_meta_sectors = 0;
>>>> @@ -874,35 +872,7 @@ static void scrub_stripe_report_errors(struct scrub_ctx *sctx,
>>>> if (test_bit(SCRUB_STRIPE_FLAG_NO_REPORT, &stripe->state))
>>>> return;
>>>>
>>>> - /*
>>>> - * Init needed infos for error reporting.
>>>> - *
>>>> - * Although our scrub_stripe infrastructure is mostly based on btrfs_submit_bio()
>>>> - * thus no need for dev/physical, error reporting still needs dev and physical.
>>>> - */
>>>> - if (!bitmap_empty(&stripe->init_error_bitmap, stripe->nr_sectors)) {
>>>> - u64 mapped_len = fs_info->sectorsize;
>>>> - struct btrfs_io_context *bioc = NULL;
>>>> - int stripe_index = stripe->mirror_num - 1;
>>>> - int ret;
>>>> -
>>>> - /* For scrub, our mirror_num should always start at 1. */
>>>> - ASSERT(stripe->mirror_num >= 1);
>>>> - ret = btrfs_map_block(fs_info, BTRFS_MAP_GET_READ_MIRRORS,
>>>> - stripe->logical, &mapped_len, &bioc,
>>>> - NULL, NULL);
>>>> - /*
>>>> - * If we failed, dev will be NULL, and later detailed reports
>>>> - * will just be skipped.
>>>> - */
>>>> - if (ret < 0)
>>>> - goto skip;
>>>> - stripe_physical = bioc->stripes[stripe_index].physical;
>>>> - dev = bioc->stripes[stripe_index].dev;
>>>> - btrfs_put_bioc(bioc);
>>>> - }
>>>> -
>>>> -skip:
>>>> + ASSERT(dev);
>>>> for_each_set_bit(sector_nr, &stripe->extent_sector_bitmap, stripe->nr_sectors) {
>>>> u64 logical = stripe->logical +
>>>> (sector_nr << fs_info->sectorsize_bits);
>>>> @@ -933,42 +903,27 @@ static void scrub_stripe_report_errors(struct scrub_ctx *sctx,
>>>> * output the message of repaired message.
>>>> */
>>>> if (repaired) {
>>>> - if (dev) {
>>>> - btrfs_err_rl_in_rcu(fs_info,
>>>> + btrfs_err_rl_in_rcu(fs_info,
>>>> "fixed up error at logical %llu on dev %s physical %llu",
>>>> logical, btrfs_dev_name(dev),
>>>> physical);
>>>> - } else {
>>>> - btrfs_err_rl_in_rcu(fs_info,
>>>> - "fixed up error at logical %llu on mirror %u",
>>>> - logical, stripe->mirror_num);
>>>> - }
>>>> continue;
>>>> }
>>>>
>>>> /* The remaining are all for unrepaired. */
>>>> - if (dev) {
>>>> - btrfs_err_rl_in_rcu(fs_info,
>>>> + btrfs_err_rl_in_rcu(fs_info,
>>>> "unable to fixup (regular) error at logical %llu on dev %s physical %llu",
>>>> logical, btrfs_dev_name(dev),
>>>> physical);
>>>> - } else {
>>>> - btrfs_err_rl_in_rcu(fs_info,
>>>> - "unable to fixup (regular) error at logical %llu on mirror %u",
>>>> - logical, stripe->mirror_num);
>>>> - }
>>>>
>>>> if (test_bit(sector_nr, &stripe->io_error_bitmap))
>>>> - if (__ratelimit(&rs) && dev)
>>>> - scrub_print_common_warning("i/o error", dev,
>>>> + scrub_print_common_warning("i/o error", dev,
>>>> logical, physical);
>>>> if (test_bit(sector_nr, &stripe->csum_error_bitmap))
>>>> - if (__ratelimit(&rs) && dev)
>>>> - scrub_print_common_warning("checksum error", dev,
>>>> + scrub_print_common_warning("checksum error", dev,
>>>> logical, physical);
>>>> if (test_bit(sector_nr, &stripe->meta_error_bitmap))
>>>> - if (__ratelimit(&rs) && dev)
>>>> - scrub_print_common_warning("header error", dev,
>>>> + scrub_print_common_warning("header error", dev,
>>>
>>> Why are we removing the rate limiting?
>>> This seems like an unrelated change.
>>
>> Because the ratelimit is not consistent.
>>
>> E.g. the "fixed up error" line is not rated limited by @rs, but by
>> btrfs_err_rl_in_rcu().
>
> That I don't understand.
>
> What I see is that scrub_print_common_warning() calls
> btrfs_warn_in_rcu() or btrfs_warn() or scrub_print_warning_inode()
> (which calls btrfs_warn_in_rcu()).
> I don't see where btrfs_err_rl_in_rcu() is called. So to me it seems
> @rs is doing the rate limiting.
>
>>
>> And we would have scrub_print_common_warning() to go btrfs_*_rl() helper
>> in the coming patches.
>
> Ok, but if @rs is indeed doing the rate limiting here, then from an
> organization point of view, it should be removed in the later patch
> that makes scrub_print_common_warning() use the btrfs_*_rl() helpers.
OK, I'll rearrange the patches so that @rs would only be removed after
we have migrate all the messages are migrated to rate limited versions.
Thanks,
Qu
>
> Thanks.
>
>>
>> Thanks,
>> Qu
>>>
>>> Everything else looks ok.
>>>
>>> Thanks.
>>>
>>>> logical, physical);
>>>> }
>>>>
>>>> --
>>>> 2.44.0
>>>>
>>>>
>>>
next prev parent reply other threads:[~2024-03-18 19:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-14 9:50 [PATCH 0/6] btrfs: scrub: refine the error messages Qu Wenruo
2024-03-14 9:50 ` [PATCH 1/7] btrfs: scrub: fix incorrectly reported logical/physical address Qu Wenruo
2024-03-14 12:24 ` Anand Jain
2024-03-14 20:15 ` Qu Wenruo
2024-04-04 20:01 ` David Sterba
2024-03-14 17:10 ` Filipe Manana
2024-03-14 9:50 ` [PATCH 2/7] btrfs: reduce the log level for btrfs_dev_stat_inc_and_print() Qu Wenruo
2024-03-14 17:17 ` Filipe Manana
2024-03-14 20:26 ` Qu Wenruo
2024-03-18 19:54 ` Filipe Manana
2024-03-14 9:50 ` [PATCH 3/7] btrfs: scrub: remove unused is_super parameter from scrub_print_common_warning() Qu Wenruo
2024-03-14 17:19 ` Filipe Manana
2024-03-14 9:50 ` [PATCH 4/7] btrfs: scrub: remove unnecessary dev/physical lookup for scrub_stripe_report_errors() Qu Wenruo
2024-03-14 17:26 ` Filipe Manana
2024-03-14 20:28 ` Qu Wenruo
2024-03-18 16:16 ` Filipe Manana
2024-03-18 19:53 ` Qu Wenruo [this message]
2024-03-14 9:50 ` [PATCH 5/7] btrfs: scrub: simplify the inode iteration output Qu Wenruo
2024-03-14 17:29 ` Filipe Manana
2024-03-14 9:50 ` [PATCH 6/7] btrfs: scrub: unify and shorten the error message Qu Wenruo
2024-03-14 17:40 ` Filipe Manana
2024-03-14 20:56 ` Qu Wenruo
2024-03-18 16:26 ` Filipe Manana
2024-03-18 20:00 ` Qu Wenruo
2024-03-14 23:05 ` kernel test robot
2024-03-15 11:44 ` kernel test robot
2024-03-14 9:50 ` [PATCH 7/7] btrfs: scrub: fix the frequency of error messages Qu Wenruo
2024-03-14 17:51 ` Filipe Manana
2024-03-14 20:32 ` Qu Wenruo
2024-03-14 17:35 ` [PATCH 0/6] btrfs: scrub: refine the " Boris Burkov
2024-03-14 20:30 ` Qu Wenruo
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=9fca4194-01cf-4b73-80e1-e1a55dd8c825@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@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