Create by-dname symlinks based on NVMe namespace UUIDs instead of controller serial numbers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
curtin |
Triaged
|
Medium
|
Unassigned |
Bug Description
Currently by-dname symlinks are created based on serial numbers of controllers.
We started getting hardware with multi-path support that uses a different naming scheme and can support multiple namespaces per controller.
It would be good to bind block device symlinks for namespaces to namespace GUIDs (NGUID) instead of controller serial numbers.
See https:/
https:/
static bool multipath = true;
module_
https:/
/*
* If multipathing is enabled we need to always use the subsystem instance
* number for numbering our devices to avoid conflicts between subsystems that
* have multiple controllers and thus use the multipath-aware subsystem node
* and those that have a single controller and use the controller node
* directly.
*/
void nvme_set_
struct nvme_ctrl *ctrl, int *flags)
{
if (!multipath) {
sprintf(
} else if (ns->head->disk) {
sprintf(
ctrl->cntlid, ns->head-
*flags = GENHD_FL_HIDDEN;
// ...
For example, with this controller and a default namespace that we wanted to use:
81:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller 172Xa/172Xb (rev 01)
uname -a
Linux node-9 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
udevadm info -q all -n /dev/nvme0n1 | grep DEVPATH
E: DEVPATH=
readlink /sys/class/
../../devices/
readlink /sys/class/
../../devices/
lsblk -p
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
/dev/sda 8:0 0 1.8T 0 disk
├─/dev/sda1 8:1 0 512M 0 part /boot/efi
└─/dev/sda2 8:2 0 1.8T 0 part /
/dev/sdb 8:16 0 1.8T 0 disk
/dev/sdc 8:32 0 1.8T 0 disk
/dev/sdd 8:48 0 1.8T 0 disk
/dev/sde 8:64 0 1.8T 0 disk
/dev/sdf 8:80 0 1.8T 0 disk
/dev/sdg 8:96 0 1.8T 0 disk
/dev/sdh 8:112 0 1.8T 0 disk
/dev/sdi 8:128 0 1.8T 0 disk
/dev/sdj 8:144 0 1.8T 0 disk
/dev/sdk 8:160 0 1.8T 0 disk
/dev/sdl 8:176 0 111.3G 0 disk
/dev/sdm 8:192 0 3.7T 0 disk
/dev/sr0 11:0 1 1024M 0 rom
/dev/nvme0n1 259:1 0 1.5T 0 disk
ls -la /dev/nvme*
crw------- 1 root root 243, 0 May 29 14:10 /dev/nvme0
brw-rw---- 1 root disk 259, 1 May 29 14:10 /dev/nvme0n1
nvme0c33n1 is hidden is not shown in /dev/ (and lsblk does not report it) because GENHD_FL_HIDDEN is applied to those block device entries:
See:
https:/
https:/
"nvme0c33n1 is hidden is not shown in /dev/ (and lsblk does not report it) because GENHD_FL_HIDDEN is applied to those block device entries:"
Is this related at all to the request?
Further, curtin will emit dname rules that use ID_WWN, which from your paste before appears to include the NGUID, no?
ID_WWN= nvme.8086- 6e766d656330- 51454d55204e564 d65204374726c- 00000001
So I think we're already doing what's needed here. Please correct me if I'm wrong.
I'd support a feature request against maas/curtin for rich NVME support (creating namespaces, using the nvme command to modify/tweak features, functions, extract IDs etc); MAAS would need to use the nvme tool to extract this info, curtin would need a new storage type (type:nvme) and config to control etc).