Re: 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?

[Jirong Feng <jirong.feng@easystack.cn>]

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. 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.

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 :)

Thanks