Wandering Thoughts archives

Using a local database to get consistent device names is a bad idea

People like consistent device names, and one of the ways that Unixes have historically tried to get them is to keep a local database of known devices and their names, based on some sort of fingerprint of the device (the MAC address is a popular fingerprint for Ethernet interfaces, for example). Over the years various Unixes have implemented this in different ways; for example, some versions of Linux auto-created udev rules for some devices, and Solaris and derivatives have /etc/path_to_inst. Unfortunately, I have to tell you that trying to get consistent device names this way turns out to be a bad idea.

The fundamental problem is that if you keep a database of local device names, your device names depend on the history of the system. This has two immediate bad results. First, if you have two systems with identical hardware running identical software they won't necessarily use the same device names, because one system could have previously had a different hardware configuration. Second, if you reinstall an existing system from scratch you won't necessarily wind up with the same device names, because your new install won't necessarily have the same history as the current system does.

(Depending on the scheme, you may also have the additional bad result that moving system disks from one machine to an identical second machine will change the device names because things like MAC addresses changed.)

Both of these problems are bad once you start dealing with multiple systems. They make your systems inconsistent, which increases the work required to manage them, and they make it potentially dangerous to reinstall systems. You wind up either having to memorize the differences from system to system or needing to assemble your own layer of indirection on top of the system's device names so you can specify things like 'the primary network interface, no matter what this system calls it'.

Now, you can have this machine to machine variation problems even with schemes that derive names from the hardware configuration. But with such schemes, at least you only have these problems on hardware that's different, not on hardware that's identical. If you have truly identical hardware, you know that the device names are identical. By extension you know that the device names will be identical after a reinstall (because the hardware is the same before and after).

I do understand the urge to have device names that stay consistent even if you change the hardware around a bit, and I sometimes quite like them myself. But I've come to think that such names should be added as an extra optional layer on top of a system that creates device names that are 'stateless' (ie don't care about the past history of the system). It's also best if these device aliases can be based on general properties (or set up by hand in configuration files), because often what I really want is an abstraction like 'the network interface that's on network X' or 'the device of the root filesystem'.

My new Linux home machine for 2018

Back in the fall I planned out a new home machine and then various things happened, especially Meltdown and Spectre (which I feel made it not a great time to get a new CPU) but also my natural inertia. This inertia sort of persisted despite a near miss scare, but in the end I wound up losing confidence in my current (now old) home machine and just wanting to get things over with, so I bit the bullet and got a new home machine (and then I wound up with questions on its graphics).

(There will be better CPUs in the future that probably get real performance boosts from hardware fixes for Meltdown and Spectre, but there are always better CPUs in the future. And on my home machine, I'm willing to run with the kernel mitigations turned off if I feel strongly enough about it.)

The parts list for my new machine is substantially the same as my initial plans, but I made a few changes and indulgences. Here's the parts list for my future reference, if nothing else:

Intel Core i7-8700K

This is the big change from my initial plans, where I'd picked the i7-8700. It's an indulgence, but I felt like it and using an overclocking capable CPU did eliminate most of my concerns over high-speed DDR4 memory. I'm not overclocking the 8700K because, well, I don't. After I didn't run into any TDP issues with my work machine and its 95W TDP Ryzen, I decided that I didn't have any concerns with the 8700K's 95W TDP either.

(My concerns about the TDP difference between the 8700K and the 8700 turn out to be overblown, but that's going to be another entry.)

Asus PRIME Z370-A motherboard

I saw no reason to change my initial choice (and it turns out Phoronix was quite positive about it too, which I only found out about later). The RGB LEDs are kind of amusing and they even show a little bit through the some air vents on the case (especially in the dark).

2x 16GB G.Skill Ripjaws V DDR4-3000 CL15 RAM

I can't remember if the G.Skill DDR4-2666 modules were out of stock at the exact point I was putting in my order, but they certainly had been earlier (when I assembled the parts list at the vendor I was going to use), and in the end I decided I was willing to pay the slightly higher cost of DDR4-3000 RAM just as an indulgence.

(Looking at the vendor I used, the current price difference is $4 Canadian.)

I opted not to try to go faster than DDR4-3000 because the RAM modules I could easily see stopped having flat CL timings above that speed; they would be eg CL 15-18-18-18 instead of a flat CL15. There were some faster modules with flat CL timings, but they were much more expensive. Since I think I care more about latency than slight bandwidth increases, I decided to stick with the inexpensive option that gave me flat latency.

Noctua NH-U12 CPU cooler

I quite liked the Noctua cooler in my work machine, so I just got the general version of it. I've been quite happy on my work machine not just with how well the Noctua cooler works, but also how quiet it is with the CPU under heavy load (and in fact it seems quite difficult to push the CPU hard enough that the Noctua's fan has to run very fast, which of course helps keep any noise down).

In short: real (and large-ish) CPU coolers are a lot better than the old stock Intel CPU coolers. I suppose this is not surprising.

(The Noctua is not inexpensive, but I'm willing to pay for quality and long term reliability.)

EVGA SuperNova G3 550W PSU

As with my work machine, the commentary on my original plans pushed me to getting a better PSU. Since I liked this in the work machine, I just got it again for the home one. It's an amusing degree of overkill for the actual measured power draw of either machine, but I don't really care about that.

(For my own future reference: always use the PSU screws that come with the PSU, not the PSU screws that may come with the case.)

Fractal Design Define R5 case

I got this in white this time around (the work version is black). The story about the colour shift is that we recently built a new Ryzen based machine for one of my co-workers and basically duplicated my work machine for the parts list, except his case is white because he didn't care and it was cheaper and in stock at the time. When his case came in and I got a chance to see it in person, I decided that maybe I liked the white version better than the black one and in the end my vacillation settled on the white one.

(When I pulled the trigger on buying the hardware, the two case colours were the same price (and both in stock). So it goes.)

LG GH24NSC0 DVD/CD Writer

I gave in to an emotional temptation beyond the scope of this entry and got an optical drive, despite what I'd written earlier. But I haven't actually installed it in the case; it's apparently enough that I could if I wanted to.

(It helps that powering the drive would be somewhat awkward, because the PSU doesn't come with SATA modular cables that are long enough or have enough plugs on them.)

I'm running the RAM at full speed by activating its XMP profile in the BIOS, which was a pleasant one-click option (without that it came up at a listed 2133 Mhz). There didn't seem to be a one-click option for 'run this at 2666 MHz with the best timings it supports', so I didn't bother trying to set that up by hand. The result appears stable and the BIOS at least claims that the CPU is still running at its official normal speed rating.

(Apparently it's common for Intel motherboards to default to running DDR4 RAM at 2133 MHz for maximum compatibility or something.)

In general I'm quite happy with this new machine. It's not perfect, but nothing seems to be under Linux, but everything works, it's pretty nice, and it's surprisingly fast. Honestly, it feels good simply to have a modern machine, especially one where I can't clearly hear the difference between an idle machine and one under CPU load.

(There's still a little bit of noise increase under full load, but it's pretty subtle and I have to really pay attention in a quiet environment to hear it. On my old machine, the stock Intel CPU cooler spinning up created a clearly audible difference in noise that I could hear over, eg, my typing. The old machine might have been improved by redoing the thermal paste, but my old work machine, with the redone paste, still had the same sort of audibility under load.)

After my experiences with UEFI on my work machine, I didn't try to switch from BIOS booting to UEFI on this one either (contrary to earlier plans for this). The two machines probably have somewhat different BIOSes (although their GUIs look very similar), but I didn't feel like taking the chance and I've wound up feeling that BIOS boot is better if you're using a mirrored root filesystem (which I am), fundamentally due to an unfortunate Linux (or Fedora) GRUB2 configuration choice.

PS: Given my experiences with Ryzen on my new work machine (eg, and), I wound up with absolutely no interest in going with a Ryzen home machine. This turned out to be a good choice in general, but that's another entry.

(The short version is on Twitter.)