From: "Guilherme G. Piccoli" <gpiccoli@canonical.com>
To: Song Liu <liu.song.a23@gmail.com>
Cc: Neil F Brown <nfbrown@suse.com>, Song Liu <songliubraving@fb.com>,
NeilBrown <neilb@suse.com>,
linux-raid <linux-raid@vger.kernel.org>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
Jay Vosburgh <jay.vosburgh@canonical.com>
Subject: Re: [PATCH] md/raid0: Fail BIOs if their underlying block device is gone
Date: Thu, 1 Aug 2019 17:28:24 -0300 [thread overview]
Message-ID: <9674ca8f-4325-3023-8a1d-39782103f55d@canonical.com> (raw)
In-Reply-To: <CAPhsuW5zB=Kik4rq9YA-xBer7Z-h-23QV4WSCWe-jvhFgGc0Cw@mail.gmail.com>
On 31/07/2019 16:56, Song Liu wrote:
> On Wed, Jul 31, 2019 at 12:54 PM Song Liu <liu.song.a23@gmail.com> wrote:
>>
>> On Tue, Jul 30, 2019 at 5:31 AM Guilherme G. Piccoli
>> <gpiccoli@canonical.com> wrote:
>>>
>>> On 29/07/2019 21:08, NeilBrown wrote:
>>>> [...]
>>>>> + if (unlikely(test_bit(MD_BROKEN, &mddev->flags))) {
>>>>> + bio_io_error(bio);
>>>>> + return BLK_QC_T_NONE;
>>>>> + }
>>>>
>>>> I think this should only fail WRITE requests, not READ requests.
>>>>
>>>> Otherwise the patch is probably reasonable.
>>>>
>>>> NeilBrown
>>>
>>> Thanks for the feedback Neil! I thought about it; it seemed to me better
>>> to deny/fail the reads instead of returning "wrong" reads, since a file
>>> read in a raid0 will be incomplete if one member is missing.
>>> But it's fine for me to change that in the next iteration of this patch.
>>
>> For reads at block/page level, we will either get EIO or valid data, right?
>>
>> If that's not the case, we should fail all writes.
>
> Oops, I meant all _reads_.
Hi Song, thanks for the feedback! After changing the patch and testing a
bit, it behaves exactly as you said, we got either valid data read from
the healthy devices or -EIO for the data tentatively read from the
failed/missing array members.
So, I'll resubmit with that change. Also, I've noticed clearing the
BROKEN flag seem unnecessary, if user stops the array in order to fix
the missing member, it'll require a re-assembly and the array is gonna
work again.
Do you / Neil considers this fix relevant to md/linear too? If so, I can
also include that in the V2.
Thanks,
Guilherme
next prev parent reply other threads:[~2019-08-01 20:28 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 19:33 [PATCH] md/raid0: Fail BIOs if their underlying block device is gone Guilherme G. Piccoli
2019-07-29 20:18 ` Roman Mamedov
2019-07-29 20:27 ` Guilherme G. Piccoli
2019-07-29 20:36 ` Roman Mamedov
2019-07-29 20:49 ` Guilherme G. Piccoli
2019-07-29 21:14 ` Reindl Harald
2019-07-30 0:08 ` NeilBrown
2019-07-30 12:30 ` Guilherme G. Piccoli
2019-07-31 19:54 ` Song Liu
2019-07-31 19:56 ` Song Liu
2019-08-01 20:28 ` Guilherme G. Piccoli [this message]
2019-08-01 22:43 ` Song Liu
2019-08-16 13:45 ` Guilherme G. Piccoli
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=9674ca8f-4325-3023-8a1d-39782103f55d@canonical.com \
--to=gpiccoli@canonical.com \
--cc=dm-devel@redhat.com \
--cc=jay.vosburgh@canonical.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=liu.song.a23@gmail.com \
--cc=neilb@suse.com \
--cc=nfbrown@suse.com \
--cc=songliubraving@fb.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