[PATCHv2] nvme: send uevent once a multipath namespace is operational again
Ewan D. Milne
emilne at redhat.com
Thu Mar 11 17:54:20 GMT 2021
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 at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-nvme
>
More information about the Linux-nvme
mailing list