[PATCH V3 0/3] Ensure ordered namespace registration during async scan

[Randy Jennings]

On Wed, Jun 24, 2026 at 4:02 PM Keith Busch <kbusch at kernel.org> wrote:
>
> > In general I fail to see the issue here.
> > Any modern distro should be using persistent device links to access
> > devices, so the actual device name is pretty much irrelevant.
> > We on our side haven't had any issues here since ages.
>
> I agree there's not a real issue here. The suggestion is purely a
> quality-of-life improvement to provide a visual clue that aligns with
> people's expectations, reducing any surprises. There are people and
> documentation that still think the "n1" in the nvme0n1 means it's NSID
> 1. If we can easily align to that, then why not? But I'm not exactly
> needing this feature either, so if you think there are some "gotcha's"
> here that may destablize the current scanning, then I have no
> problem shelving this one.

There is the issue where the NSID of a specific namespace can change
when there are no hosts connected that it is attached to.  It does not
happen often, but it can need to happen (even without namespace
migration).  This is not speculative.  Over the course of years, our array
has had to do it for specific scenarios a couple of times.

However, the more fundamental problem is this:
> That said, many users still rely on /dev/nvmeXnY links, for example for
> some nvme-cli commands. Because kernel 6.11 made these names totally
> random across reboots, it's causing some confusion for them.
Relying on NSID to fix references to a specific namespace is not a safe
way to operate.  And making the device name predictable leads to people
taking these shortcuts.  To find a specific namespace, the NGUID should
be used.  That guarantees you are on the same storage.  Enabling
shortcuts that are not reliable is not a good practice.

Sincerely,
Randy Jennings