by-dname was intended to be "by device name" and ended up to be "by data name"
Curtin docs promise disk naming and partition naming:
https://curtin.readthedocs.io/en/latest/topics/storage.html
"If the name key is present, curtin will create a udev rule that makes a symbolic link to the disk with the given name value. This makes it easy to find disks on an installed system. The links are created in /dev/disk/by-dname/<name>. A link to each partition on the disk will also be created at /dev/disk/by-dname/<name>-part<number>..."
> "What we decided was that to work our way out of this issue, we should/would provide a /dev/disk/by-<something> that would *only* consider serial numbers or wwid as basis for its names."
I think "device name" vs "data name" usage should depend on an application and we need 2 symlink types:
* a "devicename" symlink should mean a wwn or serial number symlink for hw devices themselves, for virtual devices (partitions, bcache, md-raid etc.) - a superblock unique ID symlink;
* a "dataname" symlink should mean a GPT UUID/MBR disk identifier symlink for hw devices with a partition table, partition UUID symlink for partitions, superblock UUIDs for virtual devices.
There are several classes of block devices that I see:
1) hardware block devices with a unique factory identifier (wwn, EUI etc.);
2) hardware-level virtual block devices (created by RAID controllers) - WWN stability will depend on the raid controller's implementation but generally a RAID-controller superblock is written to every device in a RAID.
3) virtual block devices. Availability of persistent and unique identifiers depends on hypervisor support and persistent configuration that a hypervisor provides (libvirt domain xml files -> qemu args, VMDK file metadata etc.)
For QEMU, IDE and SCSI devices can utilize a wwn passed via qemu command line and virtio devices can utilize a serial number parameter.
Based on https:/ /bugs.launchpad .net/curtin/ +bug/1735839/ comments/ 2
by-dname was intended to be "by device name" and ended up to be "by data name"
Curtin docs promise disk naming and partition naming:
https:/ /curtin. readthedocs. io/en/latest/ topics/ storage. html by-dname/ <name>. A link to each partition on the disk will also be created at /dev/disk/ by-dname/ <name>- part<number> ..."
"If the name key is present, curtin will create a udev rule that makes a symbolic link to the disk with the given name value. This makes it easy to find disks on an installed system. The links are created in /dev/disk/
> "What we decided was that to work our way out of this issue, we should/would provide a /dev/disk/ by-<something> that would *only* consider serial numbers or wwid as basis for its names."
I think "device name" vs "data name" usage should depend on an application and we need 2 symlink types:
* a "devicename" symlink should mean a wwn or serial number symlink for hw devices themselves, for virtual devices (partitions, bcache, md-raid etc.) - a superblock unique ID symlink;
* a "dataname" symlink should mean a GPT UUID/MBR disk identifier symlink for hw devices with a partition table, partition UUID symlink for partitions, superblock UUIDs for virtual devices.
There are several classes of block devices that I see:
1) hardware block devices with a unique factory identifier (wwn, EUI etc.);
lrwxrwxrwx 1 root root 14 Jul 25 16:28 nvme-eui. 010000000100000 05cd2e407a30d4f 51 -> ../../nvme10n1 13becef -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 25 16:28 wwn-0x5000c5008
2) hardware-level virtual block devices (created by RAID controllers) - WWN stability will depend on the raid controller's implementation but generally a RAID-controller superblock is written to every device in a RAID.
journalctl -k | grep -i lsi
JUN 08 16:38:57 ubuntu kernel: scsi 0:2:1:0: Direct-Access LSI MR9271-8i 3.46 PQ: 0 ANSI: 5
lspci | grep -i lsi
01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 2208 [Thunderbolt] (rev 05)
tree /dev/disk/by-id/ | grep sda 6deb2f0ff00001f 01ff0cdb -> ../../sda 6deb2f0ff00001f 01ff0cdb -> ../../sda
├── scsi-3600605b00
└── wwn-0x600605b00
3) virtual block devices. Availability of persistent and unique identifiers depends on hypervisor support and persistent configuration that a hypervisor provides (libvirt domain xml files -> qemu args, VMDK file metadata etc.)
For QEMU, IDE and SCSI devices can utilize a wwn passed via qemu command line and virtio devices can utilize a serial number parameter.
https:/ /git.qemu. org/?p= qemu.git; a=commit; h=95ebda85e09ed 2b7f00deb2adbda fa5ccf5db948 /git.qemu. org/?p= qemu.git; a=commitdiff; h=64cc22841e72d 37d577416f58361 55ecd0a9bfb6 /git.qemu. org/?p= qemu.git; a=commitdiff; h=9a502563eef7d 7c2c9120b237059 426e229eefe9
https:/
https:/
https:/ /libvirt. org/git/ ?p=libvirt. git;a=commitdif f;h=6e73850b01e e7d5816a803d684 e9d669dad036f3
virtio:
#... lib/libvirt/ images/ maas-1. qcow2,format= qcow2,if= none,id= drive-virtio- disk0,serial= a76f8801- 92d3-4aff- 9c96-a51a054517 a0 # ...
-drive file=/var/
cat /sys/class/ block/vda/ serial 92d3-4aff- 9
a76f8801-
(virtio)scsi:
virsh dumpxml maas | grep wwn wwn>5000c50015e a71ad</ wwn>
<
-device scsi-hd, bus=scsi0. 0,channel= 0,scsi- id=0,lun= 0,drive= drive-scsi0- 0-0-0,id= scsi0-0- 0-0,bootindex= 1,wwn=0x5000c50 015ea71ad
├── wwn-0x5000c5001 5ea71ad -> ../../sda 5ea71ad- part1 -> ../../sda1 5ea71ad- part2 -> ../../sda2
├── wwn-0x5000c5001
└── wwn-0x5000c5001
4) data-based devices (partitions, bcache, md-raid, LUKS etc.) - superblocks/headers contain UUIDs and sometimes labels.