Allow for diskio alias by UUID

[Emporea]

When declaring aliases for my disks, I realised its nonsense what I am doing, since dm-0, dm-1, dm-2, sda, sdb, sdc, sdd and so on can change with every boot, making my aliases invalid and pointing to inconsistent partitions / disks.

Is there a way, or maybe it needs to be implemented yet, that fixes this inconsistency problem by using uuid or something similar that should be constant like mapper names for alias settings?

Also I would be very interested in a custum order for disks and file sys. Currently it just orders by dm-0 to dm-N, respectivly sda1 to sdXY, but since this could potentially change with every boot it would be highly appreciated if its reorderable.

[github-actions]

This issue is stale because it has been open for 3 months with no activity.

[zatricky]

I'd like to use Glances for some basic disk monitoring functionality, especially in terms of smart data. As is, Glances is promising but it was a sad moment when I realised disks are haphazardly identified only by instantiation order.

If the device order changes then the previous stats don't match the current stats. In my example I currently have sda through sdk, no sdl (disk is dead), then sdm through sdq. Disk sdq was a replacement for sdl.

On next reboot, sda through sdk might stay the same - but I can't really be certain until after the reboot. This means all old smart data doesn't match current data and that individual disks are not identified.

I typically identify these by their id, label, or by UUID (as suggested in this issue). In shell for example:

$ ls -l /dev/disk/by-id/ | grep sdn
lrwxrwxrwx. 1 root root  9 Aug 15 19:25 ata-WDC_WD140EFGX-68B0GN0_<serialnumber> -> ../../sdn
lrwxrwxrwx. 1 root root 10 Aug 15 19:25 ata-WDC_WD140EFGX-68B0GN0_<serialnumber>-part1 -> ../../sdn1
$ ls -l /dev/disk/by-label/
total 0
lrwxrwxrwx. 1 root root 10 Aug 15 19:25 fedora_host1 -> ../../sda3
$ ls -l /dev/disk/by-uuid | grep sdn
lrwxrwxrwx. 1 root root 10 Aug 15 19:25 c7070463-a79e-44d6-a8fb-a732ada08135 -> ../../sdn1

The above three references are static and uniquely identify the same specific entities every time. For disk-specific things like smart, the serial number makes the most sense. For filesystems, the UUID makes the most sense. The label isn't as useful in this case - but it does uniquely identify the main OS installation filesystem mounted at /.

It is also worth pointing out that LVM Logical Volumes and encrypted disks/partitions also show up in /dev/mapper. These are also usually static names.

[zatricky]

I've looked into what would be needed to help resolve this ; Nicolas already opened an issue for related work a while back:
giampaolo/psutil#1609 and #1543