Wandering Thoughts archives

Link: Where Vim Came From

Where Vim Came From (via) is an interesting and thorough overview of the history of vim, vi, ed, and other predecessors (with copious footnotes). It's nice to see all of the pieces laid out this way, and I learned of some historical links that I hadn't already known.

(I do wonder what vi would have been like if ed had kept QED's multiple buffer support.)

Update, the next day: See also Dennis Ritchie's An incomplete history of the QED Text Editor (via).

Linux's /dev/disk/by-path names for disks change over time

I have in the past written about the many names of SATA disks and on the names of SAS drives, and in both cases one of the sorts of names I talked about was the /dev/disk/by-path names. Unlike the various other names of disks, which are generally kernel based, these names come from the inscrutable depths of udev. It will probably not surprise you to hear that udev periodically changes its mind about what to call things (or, sometimes, has problems figuring things out).

Due to our new fileserver hardware, I can give you two examples of how this has changed, one for SAS devices and one for SATA ones. First, for SATA disks that are directly attached to SAS ports, udev now provides disk names that use the SAS PHY number instead of the nominal 'SAS address', resulting in names like pci-0000:19:00.0-sas-phy2-lun-0. There is still a /sys/block/sdX/device/sas_address file, I believe with the same contents as before, it's just that udev now just uses the PHY number. This is convenient for us, since SAS PHY numbers seem to be the best way of identifying the physical disk slot on our hardware. Udev's SAS PHY numbers start from 0.

For SATA disks that are directly attached to SATA ports, udev now uses names that directly refer to the ataN names of the drives (at least for drives that aren't behind port multipliers; udev probably still mangles the names of SATA disks behind port multipliers). This gives you names such as pci-0000:00:17.0-ata-2. Much like the kernel, udev's ATA numbers start from one, and they're relative to the controller; our new systems have both pci-0000:00:11.5-ata-1 and pci-0000:00:17.0-ata-1 disks.

(This switch may be partly due to ATA numbers now appearing in sysfs, as very helpfully noted by Georg Sauthoff in a comment from last year on my old entry. This sysfs change happened sometime between CentOS 6's kernel (some version of 2.6.32) and CentOS 7's kernel (some version of 3.10.0).)

Notice that udev is not necessarily consistent with itself in naming standards. Directly connected SATA disks use 'ata-N', with a dash between the fixed name and the number, while SAS disks use 'phyN', with no dash. I suspect that different people write the code for different sorts of devices, and do whatever they feel is the best option.

(I believe that all of these names are hard-coded in udev itself, not set up through udev rules.)

Generally any competently run Linux distribution is not going to cause your /dev/disk/by-path names to change over the lifetime of any particular release of the distribution. They may well change from release to release, though, especially for major jumps (for example, between Ubuntu LTS releases). This is a potential issue if you have things that use these names and rely on them staying constant. One possible case is ZFS on Linux, especially given how it handles disk names; however, the usual recommendation for ZoL is to use /dev/disk/by-id names, which should really be stable over the long term.

(I don't know if they actually have been, although my ZoL pools haven't suffered any explosions due to this over the several years and fair number of Fedora releases that I've been running them.)

PS: To my surprise, none of our Ubuntu 14.04 systems even have a /dev/disk/by-path directory. I suspect that this is some 14.04 peculiarity, since CentOS 6 is even older and does have a by-path directory, and this old entry says that at least some of our 12.04 systems also had it. We don't normally use any of the /dev/disk/by-* directories on our regular Ubuntu servers, which is probably why I didn't notice before now.