About nvme char/block naming mismatch

Guilherme G. Piccoli gpiccoli at canonical.com
Tue Sep 3 21:27:49 UTC 2019

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 [0],
[1] or [2]) 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'
default configuration?
Any comments or suggestions are highly appreciated.
Thanks in advance,


lore.kernel.org/linux-nvme/20190814142836.2322-1-gpiccoli at canonical.com/T/#u

lore.kernel.org/lkml/d71107d2-c133-9f51-c271-688516641703 at deltatee.com/T/#t

[2] lore.kernel.org/linux-nvme/20190610124925.GA20319 at minwooim-desktop/T/#u

More information about the kernel-team mailing list