Wandering Thoughts archives


What I want out of stable device names

There's a modest mania in various systems of giving sysadmins stable (or 'consistent') device names. Solaris has done it for a long time, I believe that Irix had some version of it, Linux has made two attempts to do it for network devices, and so on. Before people design yet another system that makes yet another attempt at it, I believe it's worthwhile to step back and ask what we actually want out of 'stable' device names.

My bias is that two things make device names a pain to manage: device names that aren't what you'd get if you reinstalled from scratch, and device names that depend on what physical slot hardware has been placed in. Change-dependent device names mean that the same hardware has different names on different servers depending on what exactly you did to the server; this complicates management for the obvious reason. Physical slot dependent names mean that things go off the rails if you do not always install your expansion cards in exactly the same spot. This can easily happen from either mistakes or different needs due to the servers being in different spots in racks and the like.

(This assumes unique hardware, eg your servers only have one additional Ethernet card. If servers have two different Ethernet cards and you shuffle their relative locations from server to server, things are a lot less clear.)

Around here, there are three main sorts of hardware changes that we make to systems: we transplant a system to completely new hardware (often but not always it's to identical hardware), we shift what physical slot an expansion card is in (for example after we discover that we don't really want a network card in the server's bottom slot because then it's very hard to get the network cables out), and we add a new card to a system.

When I transplant a system (ie, move its system disks) to completely new hardware, the simplest explanation of what I want to happen is that I want to device names to be identical to what I'd get if I (re)installed the system on this hardware from scratch. If the new hardware is physically identical to the old hardware, this should normally result in the system reusing the same device names.

(It's not hard for the system to detect when it has been transplanted. There are very few explanations for all of your old devices disappearing at once, especially if an identical set of devices with new hardware identifiers all appear at the same time. Most especially if you know that some of the devices are onboard devices, not ones on expansion cards.)

When I shift an expansion card from slot to slot, I almost always want the device names attached to the expansion card to stay the same. The device names are effectively tied to the function of the card and that function isn't changing just because it's better to have the card in the top slot instead of the bottom one. The only exception to this is if I have several cards providing the same resource; if I shuffle the ordering of the cards, I think that the safest thing is to keep the device names attached to the card location instead of the specific physical cards.

When I add a new card to a system, I generally want existing devices to keep their current names. Certainly I think that this is the safest default option. However, I also want an easy 'rename to what you'd get if installed from scratch' option because often this is the best option for long-term management.

Some of you are going to disagree vociferously with this set of views (and for good reasons). That's okay; what it really means is that how you name devices is a policy issue, not just a technical one, and there is no 'right' answer that works for everyone. This in turn has implications for how systems should handle device (re)naming.

(The more I think about it the more I think that systems should allow device names to have aliases and then have several different naming policies for different sorts of aliases.)

sysadmin/StableDeviceNamesDesire written at 01:47:57; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.