Wandering Thoughts archives


ZFS on Linux is improving the handling of disk names on import

Back in 2017 I wrote up how ZFS on Linux names disks in ZFS pools. One of the important parts of this is that ZFS on Linux only stored a single name for each disk (the full path to it), and if the path wasn't there when you tried to import the pool (including the import during boot using a cachefile), you had a problem. The good news is that ZFS on Linux (well, OpenZFS) has recently landed a change that significantly improves this situation.

To summarize what the change does (assuming I understand it correctly), if an expected device in a pool is not found at the path for it in the cachefile (which is the same as what the pool stores), ZoL will attempt to search for all of the disks in the pool as if you were running 'zpool import'. This search has two restrictions; first, it looks for the pool by GUID instead of by name (which is what you'd expect), and second it only looks at devices in the same directory or directories as the pool's original device names. So if you specified all your devices by /dev/disk/by-path paths, the import won't scan, say, /dev or /dev/disk/by-id. In the common case this won't make a difference because all disks will be present in all the /dev directories.

(Of course this assumes that udev is populating your /dev properly and promptly.)

It looks like this change will be in ZFS on Linux 2.1.0 when that gets released (and there was a release candidate just made recently for 2.1.0, so hopefully that won't be too far away). Interested parties can read the full commit message and description in commit 0936981d8. Based on reading the code, there seems to be no way to turn this off if for some reason you really want pool import to fail unless the disks are exactly where or what you expected. You can probably effectively disable it by setting up your own directory of symlinks to your pool's disks and then arranging for your pool to use that directory in all of its device names.

(I don't know if this change is even necessary in FreeBSD. If it is, presumably it will get there someday, but I have no idea how fast things move from OpenZFS to FreeBSD.)

linux/ZFSOnLinuxDiskNamesII written at 21:57:56; Add Comment

Programs that read IPMI sensors tell you subtly different things

In my first installment, I talked about how I had started out reading IPMI sensors using ipmitool, or more specifically the command 'ipmitool sensor', which took too long on some of our machines. I then discovered that ipmi-sensors' ran quite fast on all our machines and appeared to give us the same information, so I was going to switch to it. Unfortunately it turned out that ipmi-sensors doesn't give us all of the information that ipmitool does. Fortunately I was able to find an ipmitool command that did run fast enough for the sensors we really care about: 'ipmitool -c sdr list full'. The 'full' is important, and doesn't actually seem to mean what you'd think.

Based on this Sun/Oracle documentation, the important and unclear arguments to 'ipmitool sdr list' are 'full', which really means 'temperature, power, and fan sensors' and 'compact', which really means 'failure and presence sensors' (which I think 'ipmitool sensor' will call 'discrete'). On some of our Dell servers, reading all of the various 'discrete' sensors can take some time, while reading only the temperature, power, and fan sensors runs fast enough.

Ipmitool and ipmi-sensors give the same information on a lot of sensors. However, on at least some sensors ipmitool appears to be reading additional information. For instance, on one machine ipmi-sensors reports PSUs and fans as:

3,Power Supply 1,Power Supply,N/A,N/A,'Presence detected'
13,Fan 1,Fan,N/A,N/A,'transition to Running'

Ipmitool's 'sdr list' reports the same PSU and fan as:

Power Supply 1,200,Watts,ok,10.1,Presence detected
Fan 1,39.20,percent,ok,7.1,Transition to Running

Ipmitool is somehow extracting additional readings from the IPMI that tell it the PSU wattage and the fan speed, where for some reason the ipmi-sensors standard sensor reading gives it nothing. Not all IPMI sensors need this extra information extracted (or perhaps have it), so for many of them ipmi-sensors can supply a reading (and it matches what ipmitool reports).

(The obvious assumption is that this extra reading is also why ipmitool is much slower than ipmi-sensors when reporting on some sensors on some IPMIs. My guess would be that doing the extra reading of those specific sensors is extra-slow.)

If I knew enough about how IPMIs worked and how you communicated with them, I would probably understand more of what the difference was between what the two programs are doing. As it is, I'm just thankful that I've found a way to read all of the important IPMI sensors that's fast enough. I do find it a little frustrating that the ipmitool manpage is so uninformative, and that the ipmi-sensors and ipmitool manpages seem to describe what they do the same way (at least to a non-specialist) despite clearly doing things somewhat differently.

linux/IPMISensorsProgramsMatterII written at 00:42:20; 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.