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]

>> What I think you want is to trace if the path where you disabled the 
>> namespace is actually being selected
>> over and over again, and failed over...
>>
>> Can you please activate tracing and see where your mpath commands are 
>> actually going from?
>>
>> I'd trace nvme_setup_cmd, and see that once you disable one nvmet ns, 
>> it is not selected by the mpath
>> namespace as a valid ns.
>
I keep toggling enable/disable in a single target side with an interval 
of 1 second,

and run fio in host side, the only failed one is 
4.18.0-147.3.1.el8_1.aarch64.

Please refer to the attachments. If this is not what you expect, please 
let me know and I shall test it again.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace_nvme_setup_cmd.4.18.0-305.3.1.el8.x86_64.log.gz
Type: application/x-gzip
Size: 361200 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20240429/5d28f398/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace_nvme_setup_cmd.4.18.0-147.3.1.el8_1.aarch64.log.gz
Type: application/x-gzip
Size: 85629 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20240429/5d28f398/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace_nvme_setup_cmd.6.9.0-rc5.log.gz
Type: application/x-gzip
Size: 512523 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20240429/5d28f398/attachment-0005.bin>