Disk identification

Introduction/Why?

So the one for network interface is now okay-ish. I done a quick look at how it works for… disks. So most of it was done under Linux, but I know this nightmare under OpenSolaris(I recommend 20% of Solaris Knowledge that solves 80% of your needs; but only 8 slices/partitions, non-intuitive, no file hierarchy… why), Plan9front(a bit better, at least partitions are under a directory).

And as you’re probably using lsblk and/or blkid or even fdisk -l(I use that when I’m on a non-Linux Unix) to identify as a human your disks, I done a quick look for fun at disk identifiers… (intended more for machines I guess) and… oh noes.

$ lsblk -oTRAN,NAME,SIZE,FSTYPE,PARTUUID,UUID,WWN
TRAN   NAME        SIZE FSTYPE      PARTUUID                             UUID                                 WWN
usb    sdf           2G
       └─sdf1        2G vfat
usb    sdd       931.5G
       └─sdd1    931.5G ntfs-3g     874ddc9f-01                          FEBC2BA2BC2B5505
sata   sdb         1.8T zfs_member                                       15625953673200575561                 0x11804586289146122240x
sata   sdg       111.8G crypto_LUKS                                      7979cfc6-568f-4b3a-bfc4-301c92316767 0x17202986447841742850x
sata   sdc       189.9G
       ├─sdc2    189.9G crypto_LUKS caadf50b-7419-4379-b34e-6cbdb9fb9e17 86106360-90e8-425e-b37e-33131b23a6b0
       │ └─root1 189.9G zfs_member                                       2052176674175130762
       └─sdc1        2M             d3e52e3c-2c83-48e5-af2f-8c3ce10131aa
sata   sda       189.9G
       ├─sda2      256M             b585598d-8b2c-4db8-b58c-65bfe314d57e
       ├─sda3      248M crypto_LUKS d4d61264-c2c9-4953-8c59-3ac265d986e3 9877c105-252e-4141-97df-358f14daa2a8
       └─sda1    189.4G crypto_LUKS a359857c-49eb-44c0-936c-464c150d20a0 1c578f43-6f16-497c-ba88-986609ffa1d6
         └─root  189.4G
$ blkid
/dev/sda1: UUID="1c578f43-6f16-497c-ba88-986609ffa1d6" TYPE="crypto_LUKS" PARTLABEL="encrypted" PARTUUID="a359857c-49eb-44c0-936c-464c150d20a0"
/dev/sda3: UUID="9877c105-252e-4141-97df-358f14daa2a8" TYPE="crypto_LUKS" PARTLABEL="boot-efi" PARTUUID="d4d61264-c2c9-4953-8c59-3ac265d986e3"
/dev/sdb: LABEL="seagate" UUID="15625953673200575561" UUID_SUB="11105316071247026470" TYPE="zfs_member"
/dev/sdc2: UUID="86106360-90e8-425e-b37e-33131b23a6b0" TYPE="crypto_LUKS" PARTUUID="caadf50b-7419-4379-b34e-6cbdb9fb9e17"
/dev/sdd1: LABEL="TOSHIBA EXT" UUID="FEBC2BA2BC2B5505" TYPE="ntfs" PARTUUID="874ddc9f-01"
/dev/mapper/root: LABEL="zroot" UUID="2052176674175130762" UUID_SUB="12007847542772910046" TYPE="zfs_member"
/dev/sdg: UUID="7979cfc6-568f-4b3a-bfc4-301c92316767" TYPE="crypto_LUKS"
/dev/mapper/root1: LABEL="zroot" UUID="2052176674175130762" UUID_SUB="5697203163307082646" TYPE="zfs_member"
/dev/sda2: PARTLABEL="boot" PARTUUID="b585598d-8b2c-4db8-b58c-65bfe314d57e"
/dev/sdc1: PARTUUID="d3e52e3c-2c83-48e5-af2f-8c3ce10131aa"
/dev/sdf1: SEC_TYPE="msdos" TYPE="vfat"

If you look enough at it… NONE of them works and wtf is UUID_SUB printing out of nowhere. So as you’re probably not LABEL’ing all your hard-drives because your system sucks… The only thing I found so far that is the least broken under linux(+(e)udev) is /dev/disk/by-id.

Proposition

So quick list of things that are nice/works:

• SunOS: Controller, Target-id, Drive, Slice; but moved to a tree would be better as it’s more flexible
• DISK ID (MODEL+SERIAL) and partition ID (MBR/GPT thing)
• PCI/BUS IDs (like: /proc/bus/pci/x/y in Linux)
• Plan9: disk as a directory, partitions as files, data for whole disk access
• DISK SLOT: useful when you plug (some of) your disk(s) by their slot (IDE: Primary/Secondary Master/Slave; SATA: 1,2,3…; USB: bus/network_iface equivalent?)

Here is an example of a file hierarchy of my idea, based on that:

• /dev/…/${BUS ID}/
  • by-label/${DISK LABEL} → ${DISK ID}
  • by-slot/${DISK SLOT} → ${DISK ID}
  • ${DISK ID}
    • by-label/${PARTITION LABEL} → ${PARTITION ID}
    • ${PARTITION ID}
    • raw

Know things

• labels being a free-form string it can be the same as another ID, a by-label directory have to be made
• I have not mentionned disk and partitions UUIDs, could be kept for legacy, but I’m in favor of not keeping them as they are broken
• in Plan9 there is the data file to have full access to the disk, I named it raw here as I think it’s more intiutive (and keeping the name data because of Plan9 is almost no use considering how dead Plan9 currently is compared to Linux|BSD|Solaris)
• The BUS ID directory allows to get sane DISK SLOT
• Maybe it doesn’t work for everything (please contact, fork, patch, …) but as it is about the same thing as what SunOS and Plan9 uses I think I’m safe saying : This should work and be flexible enough

Also anyway I think findfs(8) should be modified to add at least the DISK ID in it

Note: Turns out Haiku uses almost exactly my idea, I think I can make mine compatible with it (because I think that can be how good standards are made)