All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: mariusz.tkaczyk@intel.com, song@kernel.org,
	linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org,
	yukuai3@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH md-6.12 0/7] md: enhance faulty chekcing for blocked handling
Date: Wed, 9 Oct 2024 09:14:32 +0200	[thread overview]
Message-ID: <20241009091432.00001c26@linux.intel.com> (raw)
In-Reply-To: <20240830072721.2112006-1-yukuai1@huaweicloud.com>

On Fri, 30 Aug 2024 15:27:14 +0800
Yu Kuai <yukuai1@huaweicloud.com> wrote:

> From: Yu Kuai <yukuai3@huawei.com>
> 
> The lifetime of badblocks:
> 
> - IO error, and decide to record badblocks, and record sb_flags;
> - write IO found rdev has badblocks and not yet acknowledged, then this
> IO is blocked;
> - daemon found sb_flags is set, update superblock and flush badblocks;
> - write IO continue;
> 
> Main idea is that badblocks will be set in memory fist, before badblocks
> are acknowledged, new write request must be blocked to prevent reading
> old data after power failure, and this behaviour is not necessary if rdev
> is faulty in the first place.
> 
> Yu Kuai (7):
>   md: add a new helper rdev_blocked()
>   md: don't wait faulty rdev in md_wait_for_blocked_rdev()
>   md: don't record new badblocks for faulty rdev
>   md/raid1: factor out helper to handle blocked rdev from
>     raid1_write_request()
>   md/raid1: don't wait for Faulty rdev in wait_blocked_rdev()
>   md/raid10: don't wait for Faulty rdev in wait_blocked_rdev()
>   md/raid5: don't set Faulty rdev for blocked_rdev
> 
>  drivers/md/md.c     |  8 +++--
>  drivers/md/md.h     | 24 +++++++++++++++
>  drivers/md/raid1.c  | 75 +++++++++++++++++++++++----------------------
>  drivers/md/raid10.c | 40 +++++++++++-------------
>  drivers/md/raid5.c  | 13 ++++----
>  5 files changed, 92 insertions(+), 68 deletions(-)
> 


Hi,
We tested this patchset.

mdmon rework:
https://github.com/md-raid-utilities/mdadm/pull/66 

Kernel build torvalds/linux.git master:
commit e32cde8d2bd7d251a8f9b434143977ddf13dcec6

I applied this patchset on top of that.

My tests proved that:
- If only mdmon PR is applied - hangs are reproducible.
- If only this patchset is applied - hangs are reproducible.
- If both kernel patchset and mdmon rework are applied- hangs are not
  reproducible (at least until now).

It was tricky topic (I needed to deal with weird issues related to shared
descriptors in mdmon).

What the most important- there is no regression detected.

Thanks,
Mariusz

  parent reply	other threads:[~2024-10-09  7:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-30  7:27 [PATCH md-6.12 0/7] md: enhance faulty chekcing for blocked handling Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 1/7] md: add a new helper rdev_blocked() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 2/7] md: don't wait faulty rdev in md_wait_for_blocked_rdev() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 3/7] md: don't record new badblocks for faulty rdev Yu Kuai
2024-08-30 10:28   ` Mariusz Tkaczyk
2024-08-31  1:14     ` Yu Kuai
2024-09-02  8:55       ` Mariusz Tkaczyk
2024-09-02 12:37         ` Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 4/7] md/raid1: factor out helper to handle blocked rdev from raid1_write_request() Yu Kuai
2024-08-30 11:06   ` Mariusz Tkaczyk
2024-08-31  1:13     ` Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 5/7] md/raid1: don't wait for Faulty rdev in wait_blocked_rdev() Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 6/7] md/raid10: " Yu Kuai
2024-08-30  7:27 ` [PATCH md-6.12 7/7] md/raid5: don't set Faulty rdev for blocked_rdev Yu Kuai
2024-08-30 11:12 ` [PATCH md-6.12 0/7] md: enhance faulty chekcing for blocked handling Mariusz Tkaczyk
2024-10-09  7:14 ` Mariusz Tkaczyk [this message]
2024-10-10 12:38   ` Yu Kuai
2024-10-09  8:52 ` Paul Menzel
2024-10-10 12:40   ` Yu Kuai

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=20241009091432.00001c26@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=mariusz.tkaczyk@intel.com \
    --cc=song@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.