From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Xiao Ni <xni@redhat.com>
Cc: Song Liu <song@kernel.org>, linux-raid <linux-raid@vger.kernel.org>
Subject: Re: [PATCH 1/3] raid0, linear, md: add error_handlers for raid0 and linear
Date: Tue, 21 Dec 2021 14:56:28 +0100 [thread overview]
Message-ID: <20211221145628.0000144f@linux.intel.com> (raw)
In-Reply-To: <CALTww28wmeuXA5V4ReTLjH-=AZ3VbR-qHEbBMEktHRU8PQQiVg@mail.gmail.com>
Hi Xiao,
On Tue, 21 Dec 2021 09:40:50 +0800
Xiao Ni <xni@redhat.com> wrote:
> Now for a raid0, it can't remove one member disk from raid0. It
> returns EBUSY and the raid0 still can work well. It makes sense.
> Because all member disks are busy, the admin can't remove the member
> disk and mdadm gives a proper error.
EBUSY means that drive is busy but it is not. Just drive cannot be
safety removed. As I wrote in patch 2:
If "faulty" was not set then -EBUSY was returned to
userspace. It causes that mdadm expects -EBUSY if the array
becomes failed. There are some reasons to not consider this mechanism
as correct:
- drive can't be failed for different reasons.
- there are path where -EBUSY is not reported and drive removal leads
to failed array, without notification for userspace.
- in the array failure case -EBUSY seems to be wrong status. Array is
not busy, but removal process cannot proceed safe.
For compatibility reasons i cannot remove EBUSY. I left more detailed
explanation in patch 2.
> With this patch, it changes the situation. In raid0_error, it sets
> MD_BROKEN. In fact, it isn't broken. So is it really good to set
> MD_BROKEN here? In patch 62f7b1989c0 ("md raid0/linear: Mark array as
> 'broken'...), MD_BROKEN is introduced
> when the member disk disappears and the disk is really broken. For
> raid0/linear, the raid device can't work anymore.
It is broken, any md_error() call should end with appropriate action:
- drive removal (if possible)
- failing array (if cannot degrade array)
We cannot trust drive if md_error() was called, so writes will be
blocked. IMO it is reasonable- to not engage level stack, because one
or more members cannot be trusted (even if it is still accessible). Just
allow to read old data (if still possible).
Thanks,
Mariusz
next prev parent reply other threads:[~2021-12-21 13:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-16 14:52 [PATCH v2 0/3] Use MD_BROKEN for redundant arrays Mariusz Tkaczyk
2021-12-16 14:52 ` [PATCH 1/3] raid0, linear, md: add error_handlers for raid0 and linear Mariusz Tkaczyk
2021-12-17 2:00 ` Guoqing Jiang
2021-12-17 2:07 ` Guoqing Jiang
2021-12-19 3:26 ` Xiao Ni
2021-12-22 1:22 ` Guoqing Jiang
2021-12-20 9:39 ` Mariusz Tkaczyk
2021-12-19 3:20 ` Xiao Ni
2021-12-20 8:45 ` Mariusz Tkaczyk
2021-12-21 1:40 ` Xiao Ni
2021-12-21 13:56 ` Mariusz Tkaczyk [this message]
2021-12-22 1:54 ` Guoqing Jiang
2021-12-22 3:08 ` Xiao Ni
2021-12-16 14:52 ` [PATCH 2/3] md: Set MD_BROKEN for RAID1 and RAID10 Mariusz Tkaczyk
2021-12-17 2:16 ` Guoqing Jiang
2021-12-22 7:24 ` Xiao Ni
2021-12-27 12:34 ` Mariusz Tkaczyk
2021-12-16 14:52 ` [PATCH 3/3] raid5: introduce MD_BROKEN Mariusz Tkaczyk
2021-12-17 2:26 ` Guoqing Jiang
2021-12-17 8:37 ` Mariusz Tkaczyk
2021-12-22 1:46 ` Guoqing Jiang
2021-12-17 0:52 ` [PATCH v2 0/3] Use MD_BROKEN for redundant arrays Song Liu
2021-12-17 8:02 ` Mariusz Tkaczyk
2022-01-25 15:52 ` Mariusz Tkaczyk
2022-01-26 1:13 ` Song Liu
-- strict thread matches above, loose matches on Subject: below --
2022-01-27 15:39 [PATCH v3 0/3] Improve failed arrays handling Mariusz Tkaczyk
2022-01-27 15:39 ` [PATCH 1/3] raid0, linear, md: add error_handlers for raid0 and linear Mariusz Tkaczyk
2022-02-12 1:12 ` Guoqing Jiang
2022-02-14 9:37 ` Mariusz Tkaczyk
2022-02-15 3:43 ` Guoqing Jiang
2022-02-15 14:06 ` Mariusz Tkaczyk
2022-02-16 9:47 ` Xiao Ni
2022-02-22 6:34 ` Song Liu
2022-02-22 13:02 ` Mariusz Tkaczyk
2022-03-22 15:23 [PATCH 0/3] Failed array handling improvements Mariusz Tkaczyk
2022-03-22 15:23 ` [PATCH 1/3] raid0, linear, md: add error_handlers for raid0 and linear Mariusz Tkaczyk
2022-04-08 0:16 ` Song Liu
2022-04-08 14:35 ` Mariusz Tkaczyk
2022-04-08 16:18 ` Song Liu
2022-04-12 15:31 ` Mariusz Tkaczyk
2022-04-12 16:36 ` Song Liu
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=20211221145628.0000144f@linux.intel.com \
--to=mariusz.tkaczyk@linux.intel.com \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=xni@redhat.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;
as well as URLs for NNTP newsgroup(s).