[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