* [PATCHv2] nvme: send uevent once a multipath namespace is operational again
@ 2021-03-03 12:12 Hannes Reinecke
2021-03-03 12:32 ` Christoph Hellwig
2021-03-05 21:00 ` Sagi Grimberg
0 siblings, 2 replies; 5+ messages in thread
From: Hannes Reinecke @ 2021-03-03 12:12 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sagi Grimberg, Keith Busch, linux-nvme, Hannes Reinecke
In an all paths down scenario I/O will be requeued or aborted, and no
further I/O will be ongoing on this namespace.
This leaves the upper layers unable to determine if the namespace
becomes operational again eg. after a successful controller reset.
With this patch a 'change' uevent will be sent per multipathed namespace
once the underlying controller moved to LIVE and started I/O processing
by calling nvme_kick_requeue_lists().
Signed-off-by: Hannes Reinecke <hare@suse.de>
---
drivers/nvme/host/multipath.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
index 0696319adaf6..1a9e14ebe11b 100644
--- a/drivers/nvme/host/multipath.c
+++ b/drivers/nvme/host/multipath.c
@@ -97,8 +97,11 @@ void nvme_kick_requeue_lists(struct nvme_ctrl *ctrl)
down_read(&ctrl->namespaces_rwsem);
list_for_each_entry(ns, &ctrl->namespaces, list) {
- if (ns->head->disk)
- kblockd_schedule_work(&ns->head->requeue_work);
+ if (!ns->head->disk)
+ continue;
+ kblockd_schedule_work(&ns->head->requeue_work);
+ if (ctrl->state == NVME_CTRL_LIVE)
+ disk_uevent(ns->head->disk, KOBJ_CHANGE);
}
up_read(&ctrl->namespaces_rwsem);
}
--
2.29.2
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCHv2] nvme: send uevent once a multipath namespace is operational again
2021-03-03 12:12 [PATCHv2] nvme: send uevent once a multipath namespace is operational again Hannes Reinecke
@ 2021-03-03 12:32 ` Christoph Hellwig
2021-03-03 13:05 ` Hannes Reinecke
2021-03-05 21:00 ` Sagi Grimberg
1 sibling, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2021-03-03 12:32 UTC (permalink / raw)
To: Hannes Reinecke; +Cc: Christoph Hellwig, Sagi Grimberg, Keith Busch, linux-nvme
On Wed, Mar 03, 2021 at 01:12:27PM +0100, Hannes Reinecke wrote:
> In an all paths down scenario I/O will be requeued or aborted, and no
> further I/O will be ongoing on this namespace.
> This leaves the upper layers unable to determine if the namespace
> becomes operational again eg. after a successful controller reset.
> With this patch a 'change' uevent will be sent per multipathed namespace
> once the underlying controller moved to LIVE and started I/O processing
> by calling nvme_kick_requeue_lists().
This looks functionally correct, but I'm a little worried about the
nvme_kick_requeue_lists function name being a little off now. Can
anyone on the list think of a better name?
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCHv2] nvme: send uevent once a multipath namespace is operational again
2021-03-03 12:32 ` Christoph Hellwig
@ 2021-03-03 13:05 ` Hannes Reinecke
0 siblings, 0 replies; 5+ messages in thread
From: Hannes Reinecke @ 2021-03-03 13:05 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Sagi Grimberg, Keith Busch, linux-nvme
On 3/3/21 1:32 PM, Christoph Hellwig wrote:
> On Wed, Mar 03, 2021 at 01:12:27PM +0100, Hannes Reinecke wrote:
>> In an all paths down scenario I/O will be requeued or aborted, and no
>> further I/O will be ongoing on this namespace.
>> This leaves the upper layers unable to determine if the namespace
>> becomes operational again eg. after a successful controller reset.
>> With this patch a 'change' uevent will be sent per multipathed namespace
>> once the underlying controller moved to LIVE and started I/O processing
>> by calling nvme_kick_requeue_lists().
>
> This looks functionally correct, but I'm a little worried about the
> nvme_kick_requeue_lists function name being a little off now. Can
> anyone on the list think of a better name?
>
nvme_restart_processing()?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCHv2] nvme: send uevent once a multipath namespace is operational again
2021-03-03 12:12 [PATCHv2] nvme: send uevent once a multipath namespace is operational again Hannes Reinecke
2021-03-03 12:32 ` Christoph Hellwig
@ 2021-03-05 21:00 ` Sagi Grimberg
2021-03-11 17:54 ` Ewan D. Milne
1 sibling, 1 reply; 5+ messages in thread
From: Sagi Grimberg @ 2021-03-05 21:00 UTC (permalink / raw)
To: Hannes Reinecke, Christoph Hellwig; +Cc: Keith Busch, linux-nvme
> In an all paths down scenario I/O will be requeued or aborted, and no
> further I/O will be ongoing on this namespace.
> This leaves the upper layers unable to determine if the namespace
> becomes operational again eg. after a successful controller reset.
Who is upper-layers here?
> With this patch a 'change' uevent will be sent per multipathed namespace
> once the underlying controller moved to LIVE and started I/O processing
> by calling nvme_kick_requeue_lists().
>
Other than that looks reasonable to me..
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCHv2] nvme: send uevent once a multipath namespace is operational again
2021-03-05 21:00 ` Sagi Grimberg
@ 2021-03-11 17:54 ` Ewan D. Milne
0 siblings, 0 replies; 5+ messages in thread
From: Ewan D. Milne @ 2021-03-11 17:54 UTC (permalink / raw)
To: linux-nvme
On Fri, 2021-03-05 at 13:00 -0800, Sagi Grimberg wrote:
> > In an all paths down scenario I/O will be requeued or aborted, and
> > no
> > further I/O will be ongoing on this namespace.
> > This leaves the upper layers unable to determine if the namespace
> > becomes operational again eg. after a successful controller reset.
>
> Who is upper-layers here?
While a notification that I/O is unlikely to fail or get queued
waiting for a controller to reconnect does seem like a nice feature,
it seems like without some ability to notify that we have *entered*
the all paths down state, what is userspace supposed to do with a
"it's working now" uevent?
Also, what about the case where there are paths available but they
are all in the ANA INACCESSIBLE state? Isn't that the same thing from
a user perspective? This would be a common scenario e.g. when a
storage device has to change the ANA state if a array-side link fails.
-Ewan
>
> > With this patch a 'change' uevent will be sent per multipathed
> > namespace
> > once the underlying controller moved to LIVE and started I/O
> > processing
> > by calling nvme_kick_requeue_lists().
> >
>
> Other than that looks reasonable to me..
>
> _______________________________________________
> Linux-nvme mailing list
> Linux-nvme@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-03-11 17:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-03 12:12 [PATCHv2] nvme: send uevent once a multipath namespace is operational again Hannes Reinecke
2021-03-03 12:32 ` Christoph Hellwig
2021-03-03 13:05 ` Hannes Reinecke
2021-03-05 21:00 ` Sagi Grimberg
2021-03-11 17:54 ` Ewan D. Milne
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).