User-friendly disk names

Device names, particularly for disks, can be confusing to Linux administrators because they get assigned at boot time based on the order in which the disks are discovered. So the same physical disk can be assigned a different device name (in /dev) on each boot, which means that kernel log messages and the output of various utilities may not correspond with the administrator's view of the system. A recent patch set looks to change that situation, but it is meeting some resistance from kernel hackers who think it should be handled by user space.

The patches posted by Nao Nishijima are pretty straightforward. They just add a preferred_name entry to struct device, which can be updated via sysfs. The patches then change some SCSI log messages and /proc/partitions output to use the preferred name if it has been set. Greg Kroah-Hartman expressed concerns about changing /proc/partitions as various tools parse that file so it is part of the kernel's user-space interface. Adding the preferred name as a new field on each line might very well confuse utilities that parse the file.

More importantly, though, he notes that one could just change the tools so that they use the names as arguments or in their output. Any scheme that would map preferred names to specific disks requires some kind of mapping file, so tools that wanted to use these preferred names (things like mount, smartd, and other disk-related tools) could do so using that mapping without involving the kernel at all:

While the patches only use preferred_name for disk devices, the idea is to allow them to be added to any device (and then change log messages and utilities to use them). It is modeled after the ifalias entry that was added for network devices back in 2008, but some don't see that as something to emulate. Allowing only one alias for network devices is generally not enough "because people want not a single but multiple names at the same time", Kay Sievers said, so ifalias is only used by some SNMP utilities. Currently, udev maintains a set of links in /dev/disk/by-* that relate disks to kernel devices by a variety of characteristics (ID, label, path, and UUID). James Bottomley would like to see that be extended for the preferred names:

But there are problems inherent in that idea. In order for udev to know that the preferred name was set, a uevent would have to be generated. That could be done, but it leads to other problems, as Sievers points out (instead of by-preferred, he uses by-pretty):

    /dev/disk/by-pretty/foo

Essentially, udev keeps track of the devices present in the system (and their attributes like, potentially, preferred name), but doesn't have any concept of tracking "no longer valid names" as Sievers puts it. That means that udev can't just leave older entries around when user space changes the preferred name: "We can not just add stuff to /dev without a udev database entry, it would never get removed on device unplug and leave a real mess behind."

One possible solution for the renaming problem is to only allow one write to preferred_name, so that, once established, those aliases couldn't be changed without a reboot. udev could set up the proper links, and various tools could use the aliases as needed. That would solve the renaming problem at the cost of some flexibility. In general, no one was really opposed to the idea of some kind of more-mnemonic name for disks, it is more of a question of how to get there.

Sievers proposed adding a way for udev to list all of the symlinks that it creates during device discovery. Anyone (or any tool) that needed to associate an alias with a particular disk could use that output to determine the current device being used (based on the UUID for example), then make the substitution as appropriate. That would work, in general, but Bottomley sees it as overly complex for users:

But Sievers and driver core maintainer Kroah-Hartman see it as papering over more substantial issues. Sievers, at least, would like to see text-file-style debug and error message output replaced (or supplemented) with something more structured:

But, from the user's perspective, disks may already have names (with labels on the enclosures themselves for example) and it would be quite convenient for the kernel's messages to reflect them. In the end, Sievers isn't opposed to a disk-specific (rather than for all devices) solution, though he thinks it isn't really the right direction to go. Kroah-Hartman agrees and is adamant that this change not go into the driver core. Based on that, Nishijima plans to redo the patches, moving the name to struct gendisk, renaming the field to alias_name (rather than "preferred") to better reflect its purpose, and generating a uevent when the name changes.

But, following the lead of the network ifalias will add to the kernel's user-space interface, only this time for disks. While it may solve an immediate problem for administrators, it will also leave behind some legacy code when, or if, a better solution comes around. That's unfortunate, but, since it solves a real problem, and the change is restricted to subsystem whose maintainer (Bottomley) is in favor of it, it may well turn up in the mainline before long. Any change to system error and debug logging along the lines of what Sievers described is certainly quite a ways off, though there have long been calls for structured kernel output. Sometimes it is just easier to make a change like this in one place, rather than trying to identify and fix all of the places outside of the kernel that would need it.