From: Coly Li <colyli@suse.de>
To: Michael Lyle <mlyle@lyle.org>, linux-bcache@vger.kernel.org
Cc: linux-block@vger.kernel.org, tang.junhui@zte.com.cn
Subject: Re: [PATCH v1 00/10] cache device failure handling improvement
Date: Thu, 4 Jan 2018 10:20:47 +0800 [thread overview]
Message-ID: <d0c930bf-ea36-9fe5-3cce-b8f56e1b163e@suse.de> (raw)
In-Reply-To: <e53e363e-740d-5974-d989-6bf2c3a37dac@lyle.org>
On 04/01/2018 1:07 AM, Michael Lyle wrote:
> Hey Coly,
>
> On 01/03/2018 06:03 AM, Coly Li wrote:
> [snip]
>> The first 8 patches of this patch set is to fix existing bugs in bcache,
>> the last 2 patches do the real improvement. Order of applying these patches
>> is important, if the last 2 patches are applied firstly, kernel panic or
>> process hang will be observed. Therefore I suggest to apply the first 8
>> fixes, then apply the last 2 patches.
>
Hi Mike,
> Wow, this is a lot of changes. :D Thanks for the fixes. I've skimmed
> through these (no real review yet) and overall what you're doing looks
> good. I think I'm going to concentrate on the first several patches in
> the set for now as a strategy to get at least some of this in for the
> first pass of 4.16 and we can figure out what to do from there.
>
Yes, I am also testing it from my side, and after v2 patches (I will
rebase the rested patches agains bcache-for-next) our partners will join
the verification too.
> We're up to RC6, so it's getting to be time to get things into next, and
> pretty soon I need to focus on testing for awhile.
>
Thanks for doing this. When you test the patch set, please apply them
together, because the bugs that the first 8 patches try to fix won't be
triggered without applying the last 2 patches, especially the io_disable
patch.
The io_disable patch fixes dc->count reference issue, then
cache_set_flush() can be executed, and the bugs are triggered.
> [off-topic, I wasn't able to find the time to go through the lock model
> for 4.16 as I had hoped-- hopefully these changes make it to 4.17].
No rush, I am glad to review the patches once they are done.
Thanks for your effort, again :-)
Coly Li
next prev parent reply other threads:[~2018-01-04 2:20 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-03 14:03 [PATCH v1 00/10] cache device failure handling improvement Coly Li
2018-01-03 14:03 ` [PATCH v1 01/10] bcache: exit bch_writeback_thread() with proper task state Coly Li
2018-01-03 17:08 ` Michael Lyle
2018-01-05 17:05 ` Coly Li
2018-01-05 17:09 ` Michael Lyle
2018-01-08 7:09 ` Hannes Reinecke
2018-01-08 13:50 ` Coly Li
2018-01-03 14:03 ` [PATCH v1 02/10] bcache: set task properly in allocator_wait() Coly Li
2018-01-03 17:09 ` Michael Lyle
2018-01-05 17:11 ` Coly Li
2018-01-08 7:10 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 03/10] bcache: reduce cache_set devices iteration by devices_max_used Coly Li
2018-01-03 17:11 ` Michael Lyle
2018-01-08 7:12 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 04/10] bcache: fix cached_dev->count usage for bch_cache_set_error() Coly Li
2018-01-08 7:16 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 05/10] bcache: stop dc->writeback_rate_update if cache set is stopping Coly Li
2018-01-08 7:22 ` Hannes Reinecke
2018-01-08 16:01 ` Coly Li
2018-01-03 14:03 ` [PATCH v1 06/10] bcache: stop dc->writeback_rate_update, dc->writeback_thread earlier Coly Li
2018-01-08 7:25 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 07/10] bcache: set error_limit correctly Coly Li
2018-01-08 7:26 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 08/10] bcache: fix misleading error message in bch_count_io_errors() Coly Li
2018-01-03 17:14 ` Michael Lyle
2018-01-08 7:27 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 09/10] bcache: add io_disable to struct cache_set Coly Li
2018-01-08 7:30 ` Hannes Reinecke
2018-01-03 14:03 ` [PATCH v1 10/10] bcache: stop all attached bcache devices for a retired cache set Coly Li
2018-01-08 7:31 ` Hannes Reinecke
2018-01-03 17:07 ` [PATCH v1 00/10] cache device failure handling improvement Michael Lyle
2018-01-04 2:20 ` Coly Li [this message]
2018-01-04 17:46 ` Michael Lyle
2018-01-05 4:04 ` Coly Li
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=d0c930bf-ea36-9fe5-3cce-b8f56e1b163e@suse.de \
--to=colyli@suse.de \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=mlyle@lyle.org \
--cc=tang.junhui@zte.com.cn \
/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