Consumer SSD listing namespace as nvme0c0n1 instead of nvme0n1 in /sys/class/ ?

[Keith Busch]

On Thu, Dec 15, 2022 at 03:27:59PM -0600, Nick Neumann wrote:
> As part of being careful to not get bit by namespaces whose name
> format doesn't match their device
> (https://github.com/linux-nvme/nvme-cli/issues/510), I look in
> /sys/class/nvme/nvme0 to find the namespaces that belong to /dev/nvme0
> .
> 
> This has worked well on a ton of consumer NVME devices, and the
> namespace has always been of the pattern nvme0n1 . But I recently ran
> into a consumer NVME device that listed a namespace of nvme0c0n1 in
> /sys/class/nvme/nvme0, and no nvme0n1 .
> 
> Running "nvme list" returns the nvme0n1 pattern namespace, and
> attempts to use nvme0c0n1 with various tools complain that no such
> device exists.Using nvme0n1 as the namespace works.
> 
> I've tried reading articles on DM vs native multipathing but it's
> still a bit over my head. Is the way this device is presenting itself
> incorrect, or is it just an uncommon way of doing things?

This is how it will look since your namespace is reporting multipathing
capabilities, and your kernel enabled native nvme multipathing.

The block names with the "c<#>" pattern are hidden from direct use.
These represent a path to visible block handle.

You can check the relationship among these in sysfs:

  # ls -l /sys/block/nvme0n1/device
  lrwxrwxrwx 1 root root 0 Dec 16 06:40 /sys/block/nvme0n1/device -> ../../nvme-subsys0/

  # ls -l /sys/block/nvme0n1/device/nvme*
  lrwxrwxrwx 1 root root 0 Dec 16 06:39 /sys/block/nvme0n1/device/nvme0 -> ../../../pci0000:00/0000:00:05.0/nvme/nvme0/

  # ls -l /sys/block/nvme0n1/device/nvme0/ | grep nvme
  drwxr-xr-x 8 root root    0 Dec 16 06:39 nvme0c0n1/

This shows the visible block handle, nvme0n1, is attached to
nvme-subsys0, which contains exactly one controller, nvme0, and that
controller is providing exactly one namespace path: nvme0c0n1.