Emulating hdparm's standby timeout functionality



Somewhere between the last few weeks and my home server's upgrade to Debian Buster (pre-release), hdparm stopped putting the disks into standby. I had hdparm configured to put the server's disks to sleep after 10 minutes (which in hdparm speak translates to spindown_time 120). That used to work fine, until recently.

Narrowing it down

I started digging around in the hdparm manpage once more - the values are a bit of an occult science, witness this excerpt from the manpage:

A value of zero means "timeouts are disabled": the device will not automatically enter standby mode. Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours.

As you can see the number doesn't always translate to the same timeout value in minutes. Some fiddling showed I could set the spindown_time value to 59 (which is a little under 5 minutes), but anything beyond that (60 or higher) would keep the disks spinning instead of going into standby. That doesn't really work for me - say I play some music or watch something on my HTPC, pause for a bit, come back, then the server would have to wake those disks every time. That's bad for their lifespan.

A workaround

After scouring the internet and coming across a few scripts emulating hdparm's standby timeout behaviour, I found this spindown script by a Github user called 'lynix' which comes with a systemd init script and a configuration file. It takes both /dev/disk/by-id/ and /dev/sd? values, and is easy to set up. I have installed it and it works like expected: no frills. It doesn't need anything extra beyond the usual - hdparm itself of course, smartctl (part of smartmontools in Debian) and grep. Thanks to the systemd init script there's also little more to it than dropping it all into place and enabling the script to get things running at startup.

I am a happy camper again. Too bad hdparm itself doesn't seem to cut it anymore, it seems i'm not the only one affected, so I have added my observations to the Debian bug report.