> With your solution I assume that /lib/udev/hdparm would call hdparm > twice on each HDD during udev invocation, once for non-spindown options > returned by /lib/hdparm/hdparm-functions, and once through > /usr/lib/pm-utils/power.d/95hdparm-apm for spindown options.
Exactly, for the APM options, apm, spindown_time and force_spindown_time /lib/udev/hdparm will call "/usr/lib/pm-utils/power.d/95hdparm-apm" For the other option hdparm will be called the second time. But I see no problem here. Please see the updated script here: https://salsa.debian.org/debian/hdparm/blob/930796/debian/udev-scripts/hdparm With the new /lib/udev/hdparm, hdparm follows the logic below: No config (/etc/hdparm.conf doesn't list any drives): * If disk supports APM, the defaults: - on boot, -B 254 - on power, -B 254 - on battery -B 128 -S36 (3 min) * no APM support: - hdparm will not run (no config!) If disk config is present in /etc/hdparm.conf: * disk supports APM - on boot, udev will call /lib/udev/hdparm, which in turn will call /usr/lib/pm-utils/power.d/95hdparm-apm for apm options and hdparm for other options. - on power, /usr/lib/pm-utils/power.d/95hdparm-apm - on battery, defaults -B 128 -S 36, use apm_battery and spindown_time to set non-default values * no APM support: - force_spindown_time and other options are applied, apm and spindown_time are ignored For USB or FireWere disks, APM & spindown_time options are ignored, other options are applied, force_spindown_time will be applied too. There is bug, https://bugs.launchpad.net/bugs/515023 explaining why USB and FireWire drives are ignored, however the situation might have improved since then. > Custom > scripts relying on hdparm_options() function in > /lib/hdparm/hdparm-functions would still fail if force_spindown_time is > used in /etc/hdparm.conf. I would suggest implementing the conversion > code directly into hdparm_options() function to avoid code duplication, > prevent misuse, and possibly avoid calling hdparm twice on each HDD. This makes sense, but 1. hdparm-functions is the debian specific helper script. The chances that somebody will use it for custom scripts is very low. 2. force_spindown_time is a hackish workaround and in order to implement it I need to parse this option later in "95hdparm-apm" script. Implementing proper handling of "force_spindown_time" in hdparm-functions will result in bringing part of resume_hdparm_spindown() function from 95hdparm-apm in hdparm-functions code. I don't like this idea, but please feel free to implement and send me a patch. :) > > 4. Thanks for your feedback. I have done some experiments and it appears > that the -S issue comes from something else. I can only confirm that the > -S option was still working fine at the time of hdparm 9.56+ds-2 in > buster/testing (Fall 2018) and it had been working for over 5 years with > various kernel and hdparm versions. Between hdparm 9.56+ds-2 and hdparm > 9.58+ds-1, the kernel was updated (4.17.8-1 => 4.19.37-3) and there were > also changes in udev (239-7 => 241-3). To exclude hdparm, one can try to build hdparm 9.58 on a stretch system. Building it with make will also work. > > Below is a summary of what I did so far to try and debug hdparm -S: > > > A) hdparm versions tried: > > $ hdparm-jessie -V > hdparm-jessie v9.43 > > $ hdparm-stretch -V > hdparm-stretch v9.51 > > $ hdparm-buster -V > hdparm-buster v9.58 > > > B) What currently works for all versions: > > $ hdparm -y /dev/sdx > > /dev/sdx: > issuing standby command > > $ hdparm -C /dev/sdx > > /dev/sdx: > drive state is: standby > > ## Accessing a mounted partition on /dev/sdx ## > > $ hdparm -C /dev/sdx > > /dev/sdx: > drive state is: active/idle > > ## Will still work if hdparm -y is repeated at this stage ## Good, from my expirience -y works reliable most of the time, however some disks may wakeup when hdparm -C is invoked, one can use smartctl -i -n standby $disk instead. > > > C) What worked before at the time of hdparm 9.56+ds-2 (successful > spindown after the delay): > > $ hdparm -S248 /dev/sdx > > /dev/sdx: > setting standby to 248 (4 hours) > > ## Other delays not tested ## > > > D) What does not work (anymore) for all versions (hdparm runs > successfully but will not spindown after the delay): > > $ hdparm -S1 /dev/sdx > > /dev/sdx: > setting standby to 1 (5 seconds) > > $ hdparm -S10 /dev/sdx > > /dev/sdx: > setting standby to 10 (50 seconds) > > $ hdparm -S241 /dev/sdx > > /dev/sdx: > setting standby to 241 (30 minutes) > > $ hdparm -S248 /dev/sdx > > /dev/sdx: > setting standby to 248 (4 hours) Well, this is a tricky question. First of all the timeout -S248 is really long. As far as I know some disks may decide to go for standby by themselves. Are you sure that during this 4 hours there is no disk activity? Can you see that the drive goes to standby exactly after 4 hours and not 2.5? In hdparm diff between 9.56 and 9.58 I do not see APM related changes: https://salsa.debian.org/debian/hdparm/compare/upstream%2F9.56+ds...upstream%2F9.58+ds I also see no reason why a drive will go to standby in 4 hours if it doesn't work in 5 seconds with -S1 ? There is also another thing to consider. For some disks you need to set apm below 128 in order to make them accept spindown. In general apm (-B) values from 1 to 127 permit spindown, whereas values from 128 to 254 do not. 255 suppose to disable APM and spindown. Alternative solution for spindown is hd-idle which is not yet in buster but is available on salsa: https://salsa.debian.org/debian/hd-idle Best, Alex
