From: Coly Li <colyli@suse.de>
To: Eddie Chapman <eddie@ehuk.net>
Cc: Rui Hua <huarui.dev@gmail.com>,
Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
Coly Li <i@coly.li>, Michael Lyle <mlyle@lyle.org>,
Kent Overstreet <kent.overstreet@gmail.com>,
linux-bcache@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH] bcache: recover data from backing device when read request hit clean
Date: Fri, 17 Nov 2017 21:22:05 +0800 [thread overview]
Message-ID: <dc4a100c-e1c0-ff9b-4a13-a90faf8a9d06@suse.de> (raw)
In-Reply-To: <54dbc609-b448-68f6-bd9a-676fd5d21151@ehuk.net>
On 17/11/2017 8:57 PM, Eddie Chapman wrote:
> On 17/11/17 10:20, Rui Hua wrote:
>> Hi, Stefan
>>
>> 2017-11-17 16:28 GMT+08:00 Stefan Priebe - Profihost AG
>> <s.priebe@profihost.ag>:
>>> I‘m getting the same xfs error message under high load. Does this
>>> patch fix
>>> it?
>>>
>> Did you applied the patch "bcache: only permit to recovery read error
>> when cache device is clean" ?
>> If you did, maybe this patch can fix it. And you'd better check
>> /sys/fs/bcache/XXX/internal/cache_read_races in your environment,
>> meanwhile, it should not be zero when you get that err message.
>
> Hi all,
>
> I have 3 servers running a very recent 4.9 stable release, with several
> recent bcache patches cherry picked, including V4 of "bcache: only
> permit to recovery read error when cache device is clean".
>
> In the 3 weeks since using these cherry picks I've experienced a very
> small number of isolated read errors in the layer above bcache, on all 3
> servers.
>
> On one of the servers, 2 out of the 6 bcache resources have a value of 1
> in /sys/fs/bcache/XXX/internal/cache_read_races, and it is on these same
> 2 bcache resources where one read error has occurred on the upper layer.
> The other 4 bcache resources have 0 in cache_read_races and I haven't
> had any read errors on the layers above them.
>
> On another server, I have 1 bcache resource out of 10 with a value of 5
> in /sys/fs/bcache/XXX/internal/cache_read_races, and it is on that
> bcache resource where a read error occurred on one occasion. The other 9
> bcache resources have 0 in cache_read_races, and no read errors have
> occurred on the layers above any of them.
>
> On the 3rd server where some read errors occurred, I cannot verify if
> there were positive values in cache_read_races as I moved the data from
> there onto other storage, and shut down the bcache resources where the
> errors occurred.
>
> If I can provide any other info which might help with this issue, please
> let me know.
Hi Eddie,
This is very informative, thank you so much :-)
Coly Li
next prev parent reply other threads:[~2017-11-17 13:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 3:51 [PATCH] bcache: recover data from backing device when read request hit clean Rui Hua
2017-11-17 4:02 ` Michael Lyle
2017-11-17 4:25 ` Rui Hua
2017-11-18 0:57 ` Michael Lyle
2017-11-18 17:00 ` Rui Hua
2017-11-22 5:13 ` Michael Lyle
2017-11-22 6:04 ` Rui Hua
2017-11-17 6:01 ` Coly Li
2017-11-17 7:26 ` Rui Hua
[not found] ` <D393CD04-8C7A-4A8C-B23A-6C68D5544E34@profihost.ag>
2017-11-17 10:20 ` Rui Hua
2017-11-17 12:38 ` Stefan Priebe - Profihost AG
2017-11-17 12:57 ` Eddie Chapman
2017-11-17 13:22 ` Coly Li [this message]
2017-11-17 13:43 ` Eddie Chapman
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=dc4a100c-e1c0-ff9b-4a13-a90faf8a9d06@suse.de \
--to=colyli@suse.de \
--cc=eddie@ehuk.net \
--cc=huarui.dev@gmail.com \
--cc=i@coly.li \
--cc=kent.overstreet@gmail.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=mlyle@lyle.org \
--cc=s.priebe@profihost.ag \
/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).