© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Ryan,
Got the needed output, it looks like the namespace block device created on a virtual NVMe subsystem has ID_SERIAL and ID_SERIAL_SHORT referring to a particular controller:
$ readlink /sys/block/nvme0*
../devices/
../devices/
ubuntu@node-7:~$ udevadm info -q all -n /dev/nvme0n1
P: /devices/
N: nvme0n1
S: disk/by-
S: disk/by-
S: disk/by-
E: DEVLINKS=
E: DEVNAME=
E: DEVPATH=
E: DEVTYPE=disk
E: ID_MODEL=Dell Express Flash PM1725b 1.6TB AIC
E: ID_SERIAL=Dell Express Flash PM1725b 1.6TB AIC_S47ANE0M300982
E: ID_SERIAL_
E: ID_WWN=
E: MAJOR=259
E: MINOR=1
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZE
I don't have an NVMeOF setup to verify this but from what I understand a namespace can be discovered via one of multiple controllers and, therefore, may get different a ID_SERIAL or ID_SERIAL_SHORT content in a uevent. So there is a chance that the by-dname udev rule will be affected by the order of discovery of namespaces (i.e. a symlink will only be created if a namespace is discovered through the same controller that was used during commissioning).
If we matched only against ID_WWN then we would not care about the controller through which a namespace has been discovered.
> OK. I would be surprised if the udev info contained hidden values
What I meant was that both of the namespace-related entries are present in sysfs:
/sys/block/
/sys/block/nvme0n1
But only one entry is present in devtmpfs because GENHD_FL_HIDDEN flag is applied to a controller-specific gendisk in the kernel:
/dev/nvme0n1