Hi kernel team, we've been noticing a recent increase in complaints from
users about a recent behavior of nvme driver - currently, due to nvme
multipath implementation, the numbering of nvme char device does not
match the block device anymore. They might match, but that is a coincidence.
Example of a LP bug filled about this issue: bugs.launchpad.net/bugs/1792660
The most dangerous consequence of that new behavior is having users
reformatting wrong devices in nvme-cli, for example, if they don't check
before the right char/block relation. This relation is exhibited both in
the sysfs links (/sys/block ones) or in "nvme list-subsys /dev/nvmeXnY",
but this is a care most users won't have, since they never needed that
Recent attempts of discussing the topic/fixing the behavior (see ,
 or ) basically ended-up with maintainers describing their
reasoning for the change, with some suggestions to attenuate that, like
using the kernel parameter "nvme_core.multipath=0" or double-checking
the device before running commands.
That said, I'd like some input from your team about actions in order to
prevent problems for the users - do we have any documentation about this
new nvme behavior? Would be feasible to have "nvme_core.multipath=0" as
a default parameter (perhaps with a warn comment) in bootloaders'
Any comments or suggestions are highly appreciated.
Thanks in advance,