From: Andy Smith <andy@strugglers.net>
To: linux-raid@vger.kernel.org
Subject: Re: "md/raid10:md5: sdf: redirecting sector 2979126480 to another mirror"
Date: Tue, 12 Jan 2021 02:03:36 +0000 [thread overview]
Message-ID: <20210112020336.GJ3712@bitfolk.com> (raw)
In-Reply-To: <a5c10248-9835-dec9-2ac2-a72b9a49deff@cloud.ionos.com>
Hi Guoqing,
Thanks for following up on this. I have a couple of questions.
On Tue, Jan 12, 2021 at 01:36:55AM +0100, Guoqing Jiang wrote:
> On 1/7/21 00:27, Andy Smith wrote:
> >err_rdev there can only be set inside the block above that starts
> >with:
> >
> > if (r10_bio->devs[slot].rdev) {
> > /*
> > * This is an error retry, but we cannot
> > * safely dereference the rdev in the r10_bio,
> > * we must use the one in conf.
> >
> >…but why is this an error retry? Nothing was logged so how do I find
> >out what the error was?
>
> This is because handle_read_error also calls raid10_read_request, pls see
> commit 545250f2480 ("md/raid10: simplify handle_read_error()").
So if I understand you correctly, this is a consequence of
raid10_read_request being reworked so that it can be called by
handle_read_error, but in my case it is not being called by
handle_read_error but instead raid10_make_request and is incorrectly
going down an error path and reporting a redirected read?
From my stack trace it seemed that it was just
raid10.c:__make_request that was calling raid10_read_request but I
could not see where in __make_request the r10_bio->devs[slot].rdev
was being set, enabling the above test to succeed. All I could see
was a memset to 0.
I understand that your patch makes it so this test can no longer
succeed when being called by __make_request, meaning that aside from
not logging about a redirected read it will also not do the
rcu_read_lock() / rcu_dereference() / rcu_read_unlock() that's in
that if block. Is that a significant amount of work that is being
needlessly done right now or is it trivial?
I'm trying to understand how big of a problem this is, beyond some
spurious logging.
Right now when it is logging about redirecting a read, does that
mean that it isn't actually redirecting a read? That is, when it
says:
Jan 11 17:10:40 hostname kernel: [1318773.480077] md/raid10:md3: nvme1n1p5: redirecting sector 699122984 to another mirror
in the absence of any other error logging it is in fact its first
try at reading and it will really be using device nvme1n1p5 (rdev)
to satisfy that?
I suppose I am also confused why this happens so rarely. I can only
encourage it to happen a couple of times by putting the array under
very heavy read load, and it only seems to happen with pretty high
performing arrays (all SSD). But perhaps that is the result of the
rate-limited logging with pr_err_ratelimited() causing me to only
see very few of the actual events.
Thanks again,
Andy
next prev parent reply other threads:[~2021-01-12 2:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 23:27 "md/raid10:md5: sdf: redirecting sector 2979126480 to another mirror" Andy Smith
2021-01-11 17:27 ` Andy Smith
2021-01-12 0:36 ` Guoqing Jiang
2021-01-12 2:03 ` Andy Smith [this message]
2021-01-12 11:30 ` Guoqing Jiang
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=20210112020336.GJ3712@bitfolk.com \
--to=andy@strugglers.net \
--cc=linux-raid@vger.kernel.org \
/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