Should NVME_SC_INVALID_NS be translated to BLK_STS_IOERR instead of BLK_STS_NOTSUPP so that multipath(both native and dm) can failover on the failure?

[Keith Busch]

On Tue, Dec 05, 2023 at 05:40:35AM +0100, Christoph Hellwig wrote:
> On Mon, Dec 04, 2023 at 09:37:56PM -0700, Keith Busch wrote:
> > So the controller through that path used to be able to access the
> > Namespace, then suddenly lost ability to do so, but some other path can
> > still access it if we retry on a failover/alternate path? I think your
> > target is returning the wrong error code. It should be SCT/SC 303h,
> > Asymmetric Access Persistent Loss (NVME_SC_ANA_TRANSITION), for what
> > you're describing.
> 
> Yes, assuming ANA is actually supported by the controllers..

Even without ANA, "Invalid Namespace" is still the wrong status code
when dynamic namespace attachement is supported. If the namespace still
exists in the subsystem but not attached to the controller processing a
command (i.e. "inactive"), the return needs be Invalid Field in Command:

  Specifying an inactive namespace identifier (refer to section 3.2.1.4)
  in a command that uses the namespace identifier shall cause the
  controller to abort the command with a status code of Invalid Field in
  Command