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?

[Sagi Grimberg]

> Now I suspect that my testcase is inappropriate for nvme native multipath.
> according to the base spec, chapter 2.4.1, nvme native multipath aims at
> accessing a certain namespace through multiple paths, not how to group
> different namespaces into one device. Therefore, in fabrics' case, a
> namespace must belong to one subsystem on a single target server.

Nothing restricts a subsystem to a single server.

You can expose the same subsystem from two different servers afair (as
well as the same nsid uuid, ana groups etc).

> Looking at
> the latest code of nvme driver host, the host does refuse those namespaces
> reporting the same uuid on two different subsystems(in function
> nvme_global_check_duplicate_ids), which is exactly what I'm doing. The
> testcase seems to be a misuse of nvme native multipath.

multipathing scope is within a subsystem as far as linux is concerned.

> However, the testcase is pretty reasonable for dm-mpath. In a cloud 
> scenario,
> we usually need a volume to be synced and exposed on multiple target 
> servers
> for high availability reason. dm-mpath can do that, only if we choose 
> group by
> serial. Namespaces from different subsystems reporting different uuid, but
> with same serial, can be recognized as one device by dm-mpath.
> 
> The only problem seems just to be the returning code for dm-mpath to
> failover. native mpath should not encounter this case.
> 
> please correct me if I'm wrong :)

As mentioned, afair (Hannes can correct me if I'm wrong) you can
make an nvmet subsystem span more than 1 server assuming that the
backend device is consistent (i.e. using drbd). The only thing that
you need to pay attention is that the cntlid range is not overlapping
in each of the servers that expose the nvmet subsystem (cntlid_min/max
configfs attributes).