From: Wols Lists <antlists@youngman.org.uk>
To: "Guilherme G. Piccoli" <guilherme@gpiccoli.net>,
Song Liu <liu.song.a23@gmail.com>
Cc: "Guilherme G. Piccoli" <gpiccoli@canonical.com>,
linux-block@vger.kernel.org,
linux-raid <linux-raid@vger.kernel.org>,
dm-devel@redhat.com, axboe@kernel.dk,
Gavin Guo <gavin.guo@canonical.com>,
Jay Vosburgh <jay.vosburgh@canonical.com>,
kernel@gpiccoli.net, Ming Lei <ming.lei@redhat.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios
Date: Wed, 8 May 2019 17:52:59 +0100 [thread overview]
Message-ID: <5CD3096B.4030302@youngman.org.uk> (raw)
In-Reply-To: <0ad36b2f-ec36-6930-b587-da0526613567@gpiccoli.net>
On 08/05/19 15:52, Guilherme G. Piccoli wrote:
> Hi, I understand your concern. But all other raid levels contains
> failure-event mechanisms. For example, in all my tests with raid5 or
> raid1, it first complained the device was removed, then it failed in
> super_written() when no other available device was present.
> On the other hand, raid0 does "blind-writes": it just selects the device
> in which that bio should be written (given the stripe math) and change
> the bio's device, sending it back via generic_make_request(). It's
> dummy, but not in a bad way, but rather for performance reasons. It has
> no "intelligence" for failures, as all other raid levels.
>
> That said, we could fix md.c for all raid levels, but I personally think
> it's a bazooka shot, only raid0 shows consistently this issue.
>
The academic in me says we should push that error handling into
generic_make_request() or some raid function in md.c that deals with
those problems. Sounds like there's a fair bit of duplicate
functionality that could be re-factored out.
>>
>> Academic purity versus engineering practicality :-)
>
> Heheh you have good points here! Thanks for the input =)
> Cheers,
>
Doesn't help when there's not an architect to design an overall "grand
scheme", but my usual way of working is to design top down academically,
and then ask myself "what do I need" before implementing bottom-up.
Hopefully with a load of documentation saying "I haven't done this
because I don't need it, but this is where it goes".
Cheers,
Wol
next prev parent reply other threads:[~2019-05-08 16:52 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 22:37 [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request() Guilherme G. Piccoli
2019-04-30 22:37 ` [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios Guilherme G. Piccoli
2019-05-06 16:50 ` Song Liu
2019-05-06 18:48 ` Guilherme G. Piccoli
2019-05-06 21:07 ` Song Liu
2019-05-07 21:51 ` Guilherme G. Piccoli
2019-05-08 9:29 ` Wols Lists
2019-05-08 9:29 ` Wols Lists
2019-05-08 14:52 ` Guilherme G. Piccoli
2019-05-08 16:52 ` Wols Lists [this message]
2019-05-17 16:19 ` Guilherme G. Piccoli
2019-05-20 16:23 ` Song Liu
2019-05-20 19:25 ` Guilherme Piccoli
2019-04-30 22:55 ` [PATCH 1/2] block: Fix a NULL pointer dereference in generic_make_request() Bart Van Assche
2019-04-30 22:55 ` Bart Van Assche
2019-05-17 3:33 ` Eric Ren
2019-05-17 16:17 ` Guilherme G. Piccoli
2019-05-20 2:43 ` Eric Ren
2019-05-17 22:04 ` Ming Lei
-- strict thread matches above, loose matches on Subject: below --
2019-05-23 17:23 Song Liu
2019-05-23 17:23 ` [PATCH 2/2] md/raid0: Do not bypass blocking queue entered for raid0 bios Song Liu
2019-05-23 17:23 ` Song Liu
2019-06-12 12:40 ` Guilherme Piccoli
2019-06-12 12:48 ` Greg KH
2019-06-12 16:38 ` Guilherme G. Piccoli
2019-06-12 16:37 ` Guilherme G. Piccoli
2019-06-12 16:49 ` Greg KH
2019-06-12 18:07 ` Guilherme Piccoli
2019-06-12 18:36 ` Greg KH
2019-06-12 18:43 ` Sasha Levin
2019-06-12 18:43 ` Sasha Levin
2019-06-12 18:48 ` Guilherme 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=5CD3096B.4030302@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=axboe@kernel.dk \
--cc=dm-devel@redhat.com \
--cc=gavin.guo@canonical.com \
--cc=gpiccoli@canonical.com \
--cc=guilherme@gpiccoli.net \
--cc=jay.vosburgh@canonical.com \
--cc=kernel@gpiccoli.net \
--cc=linux-block@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=liu.song.a23@gmail.com \
--cc=ming.lei@redhat.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=stable@vger.kernel.org \
/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.