About nvme char/block naming mismatch

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

About nvme char/block naming mismatch

Guilherme G. Piccoli-2
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/[hidden email]/T/#u

lore.kernel.org/lkml/[hidden email]/T/#t

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

kernel-team mailing list
[hidden email]