OK, I now hope you will understand how these UUIDs work and remember that when you need to remember it. . E.G.:
When you create a new file system on the same partition, the UUID will change and thus you have to adapt /etc/fstab and the like.
When you make a byte for byte copy of the contents of a partition (or other container) by dd or similar ( some call this “cloning”), you will have two file system with the same UUID, which of course makes them not Unique anymore and what may be worse, they will be dangerously close to each other.
That doesn’t seem to be widely known.
Maybe someone should tell the developers … e. g. of ksysguard (that’s where I became aware of the change).
To be honest, after lots years of using S.u.S.E./SUSE/openSUSE, I would never have questioned the stable order of the drives either.
Just to be clear, addressing using a unique ID is of course the best solution.
Using UUIDs in /etc/fstab for persistent device naming of mass storage is already the default at installation of openSUSE since years and many versions. I assume that most other distributions do the same. I can hardly imagine that developers of important Linux software that use addressing of mass storage (thus not on the file level) are not aware of this.
In case I was still not clear enough in my last posting:
I use UUID addressing in fstab as long as I can think of it (maybe since late 90s).
I repeat, I consider UUID as best practice. I wrote it like that. Read my posting. So what’s your point.
Ksysguard doesn’t offer disk sensors by UUID. Blame this on the developers, don’t blame this on me.
They had two decades to respect the specifications. I wanted to defend their honour (read my posting), but now I’m standing in the line of fire.
Why?
I agree with you but I must point out that the tools are sometimes discordant.
In my case I installed the server in 2017 and did some changes in the partitions in 2021 (problem with the usrmerge)
I used labels for the partitions (refering to the mount point) and the short name (/dev/sd??) for raw disk/partiton and for the swap.
This worked without problem but with recent changes the short names are not more reliable.
Now the tools
The blkid command: the man says “It is recommended to use lsblk(8) command to get information about block devices, or lsblk --fs to get an overview of filesystems, or findmnt(8) to search in already mounted filesystems” It does not show raw partitions/disk (they don"t have UUID) and shows the labels but not the mount points
The mount command also shows the short name, and with option " -l", the Labells are displayed.
Raw disk/partitions are obviously not shown
hpprol2:~ # mount -l
/dev/sdc2 on / type ext4 (rw,relatime,stripe=192) [Tumbleweed]
devtmpfs on /dev type devtmpfs (rw,nosuid,size=4096k,nr_inodes=1647533,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=2642436k,nr_inodes=819200,mode=755,inode64)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=33,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21674)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
xenfs on /proc/xen type xenfs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=6606088k,nr_inodes=1048576,inode64)
/dev/sda3 on /local type ext4 (rw,relatime,stripe=192,data=ordered) [local]
/dev/sda4 on /opt type ext4 (rw,relatime,stripe=192,data=ordered) [opt]
/dev/sda2 on /var type ext4 (rw,relatime,stripe=192,data=ordered) [var]
/dev/sda1 on /srv type ext4 (rw,relatime,stripe=192,data=ordered) [srv]
/dev/sdc4 on /home type ext4 (rw,relatime,stripe=192,data=ordered) [home]
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
gvfsd-fuse on /root/.gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=1321216k,nr_inodes=330304,mode=700,inode64)
gvfsd-fuse on /run/user/0/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1321216k,nr_inodes=330304,mode=700,uid=1000,gid=100,inode64)
portal on /run/user/1000/doc type fuse.portal (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=100)
the “fdisk -l” command use the short name and raw disk/partitions are shown
hpprol2:~ # fdisk -l
Disk /dev/sda: 300 GiB, 322122547200 bytes, 629145600 sectors
Disk model: LOGICAL VOLUME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 786432 bytes
Disklabel type: dos
Disk identifier: 0x0005f844
Device Boot Start End Sectors Size Id Type
/dev/sda1 1536 209713151 209711616 100G 83 Linux
/dev/sda2 209713152 419424767 209711616 100G 83 Linux
/dev/sda3 419424768 524281343 104856576 50G 83 Linux
/dev/sda4 524281344 629145599 104864256 50G 83 Linux
Disk /dev/sdb: 238.09 GiB, 255651102720 bytes, 499318560 sectors
Disk model: LOGICAL VOLUME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 786432 bytes
Disklabel type: dos
Disk identifier: 0x0001a1e7
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2 499122209 499122208 238G 83 Linux
Partition 1 does not start on physical sector boundary.
Disk /dev/sdc: 300 GiB, 322122547200 bytes, 629145600 sectors
Disk model: LOGICAL VOLUME
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 262144 bytes / 786432 bytes
Disklabel type: dos
Disk identifier: 0x000aab75
Device Boot Start End Sectors Size Id Type
/dev/sdc1 1536 25173503 25171968 12G 82 Linux swap / Solaris
/dev/sdc2 * 25175040 276831743 251656704 120G 83 Linux
/dev/sdc4 276831744 629145599 352313856 168G 83 Linux
Seems that we are missing the UUID on some tools.
Using UUID in the commands is also more difficult than short names when you don’t have copy paste options. (f.ex: in console Alt-ctrl-FX)
Nothing stops you from using the short names as long as you are sure these names refer to the correct devices. All tools you mentioned show you the current system state, and as long as the same devices remain connected the names shown by these tools remain correct for the current boot.
You just cannot assume that the same device will alway get the same name after reboot, that’s all. You cannot even be sure the same device gets the same name if you disconnect and then reconnect it again.
I do not know ksysguard, but when you talk about disk sensors, I can understand that they do not use UUIDs, because these belong to file systems and not to disks.
ksysguard supports monitoring performance data of disks as well as of partitions (among lots of other operating data).
I’m monitoring the transfer rates on a per-partition basis, so the UUID would guarantee a clear assignment between the graphs and the physical devices.
Looking at the devices themselves, it seems like only/dev/disk/by-path could clearly identify each physical device.
But I shouldn’t complain. Other people may have much bigger problems with this new way of non-deterministic drive assignment.
No, It identifies a file system. And tomorrow you may have a different file system on the same partition.
For partitions defined in a GPT you could use the by-partuuid (or by-partlabel if you assigned one).
Even that is not for sure. You can exchange disks and then they will have new paths.
I think the by-id come most near that goal. Although it depends of course on what the manufacturer puts there.
In short, I am a strong supporter of using the identificators that belong to the entities. And a file system is NOT a partition. And a path to a device is NOT the device.
erlangen:~ # lsblk --help
Usage:
lsblk [options] [<device> ...]
...
Available output columns:
ALIGNMENT alignment offset
ID-LINK the shortest udev /dev/disk/by-id link name
ID udev ID (based on ID-LINK)
DISC-ALN discard alignment offset
DAX dax-capable device
DISC-GRAN discard granularity
DISK-SEQ disk sequence number
DISC-MAX discard max bytes
DISC-ZERO discard zeroes data
FSAVAIL filesystem size available
FSROOTS mounted filesystem roots
FSSIZE filesystem size
FSTYPE filesystem type
FSUSED filesystem size used
FSUSE% filesystem use percentage
FSVER filesystem version
GROUP group name
HCTL Host:Channel:Target:Lun for SCSI
HOTPLUG removable or hotplug device (usb, pcmcia, ...)
KNAME internal kernel device name
LABEL filesystem LABEL
LOG-SEC logical sector size
MAJ:MIN major:minor device number
MIN-IO minimum I/O size
MODE device node permissions
MODEL device identifier
MQ device queues
NAME device name
OPT-IO optimal I/O size
OWNER user name
PARTFLAGS partition flags
PARTLABEL partition LABEL
PARTN partition number as read from the partition table
PARTTYPE partition type code or UUID
PARTTYPENAME partition type name
PARTUUID partition UUID
PATH path to the device node
PHY-SEC physical sector size
PKNAME internal parent kernel device name
PTTYPE partition table type
PTUUID partition table identifier (usually UUID)
RA read-ahead of the device
RAND adds randomness
REV device revision
RM removable device
RO read-only device
ROTA rotational device
RQ-SIZE request queue size
SCHED I/O scheduler name
SERIAL disk serial number
SIZE size of the device
START partition start offset
STATE state of the device
SUBSYSTEMS de-duplicated chain of subsystems
MOUNTPOINT where the device is mounted
MOUNTPOINTS all locations where device is mounted
TRAN device transport type
TYPE device type
UUID filesystem UUID
VENDOR device vendor
WSAME write same max bytes
WWN unique storage identifier
ZONED zone model
ZONE-SZ zone size
ZONE-WGRAN zone write granularity
ZONE-APP zone append max bytes
ZONE-NR number of zones
ZONE-OMAX maximum number of open zones
ZONE-AMAX maximum number of active zones
For more details see lsblk(8).
erlangen:~ #
All that you wrote is definitely right. Maybe I led you in a wrong direction by not mentioning that in my case it’s not essential whether the measured transfer rates relate to a filesystem, a partition, or a drive. Sorry for that.
My central points of criticism are that such a radical change seems to have been so poorly announced beforehand (if at all) and so poorly respected by application developers.
Or is ist just the application developers being not observant/serious/professional enough?
To me the consequences are only annoying (maybe I’ll write a script to tell me “Howdy, today the nvme0 graph is for the Samsung drive, and the nvme1 graph is for the Lexar drive”, according to ksysguard’s limitations), but for other users the consequences might be disastrous in a worst case.
Maybe one could have chosen an other approach, for example marking the existing interface as deprecated for a while and then abandon it, forcing developers to adapt their code. But considerations like these are too late, anyway.
The fact that device enumeration may not consistent over different boots (mostly because new busses and/or devices are added or removed) is as old as Unix. And it still was and is in Linux since the beginning of it. It is only later that things like UUIDs and VOLUME LABELS became used by the majority of file systems and then it of course took some time to see that that could help in addressing them in a more consistent and predictable way. This started with creating the symbolic links in /dev/disk/ (already years ago, I assume even before usdisk became to tool to do this). Then it took some time for distribution builders to decide what were the pros and cons of using the different possibilities (by-path, by-id, by uuid, etc.) and to implement the result to be used as defaults in their installation procedures. Again, for openSUSE this started already years ago.
At those times the symbolic links were used. But the developers of the mount command thought that they could offer a different (I assume they thought better) interface by using keyword parameters (e.g. UUID=... and LABEL=...). Again already years ago.
So this process of predictable naming is not new and as I see it there is no new development for years. What is the “radical change” here?
What is radical is that without a substantial warning quite a few systems are having issues. Many admins/users are now puzzling over what has happened and what precisely is the cause. Many that have not yet rebooted will find fun-times ahead.
While this is theoretically true that this change is not radical, historically the order of /dev/sd* has have been somewhat trustworthy for the a large number of users since the beginning in 1992. Over time references to /dev/sd* has become buried in grub configs, fstab and other boot time scripts that configure specific hardware attributes (using hdparm or smartctl). There are also many examples in existence that use /dev/sd* setting traps for the unwary. Now the ordering of /dev/sd* has gone from somewhat stable to definitely unstable, so that’s bound to catch some folk out.
I’m not trying to attribute blame or flame, I’m just noting that this is a change in past behaviour that’s causing trouble, and no one really seems to know for sure what has caused it.
@mchnz and as always recommended by users of Tumbleweed, is to follow the Factory Mailing list where information about upcoming changes is provided for example SCSI device identification and SCSI symlink generation in sg3_utils 1.48 on 09/21/2023.
Yes, I was actually aware of that and was prepared for some fallout. However, it did not clearly state that /dev/sda* would wind up being much less stable than before. In fact /dev/sd* wasn’t mentioned and the post specifically stated
This article is specifically about SCSI symlinks, which have the
format /dev/disk/by-id/scsi-*.
If you don't use dm-multipath, and don't use hardware IDs to refer to
any disks or partitions anywhere, you can stop reading here.
It was only by implication that I presumed some trouble might be coming down the line for references to /dev/sd*. In fact I assumed I would probably be OK and went back to sleep, but of course at some point I rebooted and found myself in emergency mode (fstab was OK it was using labels, but at some point many moons ago I had turned off UUID for grub - ouch).
The email and wiki page was q quite thoughtful heads-up, but it would have been even better if the heading and text mentioned all references to /dev/sd* will now be much more unstable over boots. Perhaps a heading like Stop referring to /dev/sd* before release XYZZY or you’ll be sorry
Whilst I immediately made the connection, there are quite a few current posts/emails concerning booting problems that haven’t considered, or ruled out, sg3_utils as the issue because the penny may not have drop for those users/admins.
. E.G.:
