From: Christoph Hellwig <hch@lst.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Keith Busch <kbusch@kernel.org>, Chao Leng <lengchao@huawei.com>,
Christoph Hellwig <hch@lst.de>,
linux-nvme@lists.infradead.org, Sagi Grimberg <sagi@grimberg.me>
Subject: Re: [PATCH 4/4] nvme: redirect commands on dying queue
Date: Tue, 18 Aug 2020 08:32:39 +0200 [thread overview]
Message-ID: <20200818063239.GC1754@lst.de> (raw)
In-Reply-To: <20200817152321.GD30005@redhat.com>
On Mon, Aug 17, 2020 at 11:23:22AM -0400, Mike Snitzer wrote:
> On Mon, Aug 17 2020 at 4:15am -0400,
> Christoph Hellwig <hch@lst.de> wrote:
>
> > From: Chao Leng <lengchao@huawei.com>
> >
> > If a command send through nvme-multipath failed on a dying queue, resend it
> > on another path.
> >
> > Signed-off-by: Chao Leng <lengchao@huawei.com>
> > [hch: rebased on top of the completion refactoring]
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
>
> Did we ever learn from Chao what the original issue was? Deciding to
> failover on completion because blk_queue_dying(), without any other
> insight, is definitely new to me.
Yes. Basically the controller is going away after returning a retryable
error.
> But this looks fine, just in general such blk_queue_dying() checks are
> pretty racey right? Feels like this might paper over something else but
> without knowing more:
But I guess the race doesn't matter - if we lose it, ->queue_rq will
fail and the submission path will pick another path as well.
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
next prev parent reply other threads:[~2020-08-18 6:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 8:15 nvme completion handling refactor and fix v2 Christoph Hellwig
2020-08-17 8:15 ` [PATCH 1/4] nvme: rename and document nvme_end_request Christoph Hellwig
2020-08-17 14:53 ` Mike Snitzer
2020-08-17 8:15 ` [PATCH 2/4] nvme: refactor command completion Christoph Hellwig
2020-08-17 15:08 ` Mike Snitzer
2020-08-17 19:28 ` Mike Snitzer
2020-08-18 6:26 ` Christoph Hellwig
2020-08-17 8:15 ` [PATCH 3/4] nvme: just check the status code type in nvme_is_path_error Christoph Hellwig
2020-08-17 15:11 ` Mike Snitzer
2020-08-17 19:31 ` Sagi Grimberg
2020-08-18 6:31 ` Christoph Hellwig
2020-08-17 8:15 ` [PATCH 4/4] nvme: redirect commands on dying queue Christoph Hellwig
2020-08-17 15:23 ` Mike Snitzer
2020-08-18 6:32 ` Christoph Hellwig [this message]
2020-08-17 18:10 ` nvme completion handling refactor and fix v2 Sagi Grimberg
2020-08-18 6:33 ` Christoph Hellwig
2020-08-18 7:11 nvme completion handling refactor and fix v3 Christoph Hellwig
2020-08-18 7:11 ` [PATCH 4/4] nvme: redirect commands on dying queue Christoph Hellwig
2020-08-19 10:01 ` Chao Leng
2020-08-19 10:50 ` Christoph Hellwig
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=20200818063239.GC1754@lst.de \
--to=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=lengchao@huawei.com \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
--cc=snitzer@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 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.