Hi Alex, Thanks for your detailed reply.
2. I agree that it is appropriate to drop /etc/apm/event.d/20hdparm. 3. Your solution is OK: Calling /usr/lib/pm-utils/power.d/95hdparm-apm from /lib/udev/hdparm would fix the force_spindown_time conversion issue. 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. 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. 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). 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 ## 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) Best regards, Sebastien On Mon, Jun 24, 2019 at 4:54 PM Alex Mestiashvili <ames...@rsh2.donotuse.de> wrote: > > On 6/20/19 8:42 PM, Sébastien Béhuret wrote: > > Package: hdparm > > Version: 9.58+ds-1 > > Severity: serious > > > > Dear Maintainers, > > > > In this version of hdparm, a new option 'force_spindown_time' was > > introduced to set the spindown time for disks that don't support APM. > > This option is supposed to translate to hdparm -S, similarly to the > > original option 'spindown_time'. > > > > hdparm package comes with 3 main scripts: > > > > 1) /usr/lib/pm-utils/power.d/95hdparm-apm > > This script will translate 'force_spindown_time' to hdparm -S and apply > > the option even if APM was not detected. > > This is the desired behavior. > > > > 2) /etc/apm/event.d/20hdparm > > This script will ignore /etc/hdparm.conf and apply hard-coded defaults > > instead. > > This behavior is unexpected. > > Expected/Desired behavior: Read /etc/hdparm.conf and apply relevant > options. > > > > 3) /lib/hdparm/hdparm-functions (sourced from /lib/udev/hdparm, which is > > invoked by udev rule /lib/udev/rules.d/85-hdparm.rules) > > - 'force_spindown_time' is buggy because it is not converted back to -S, > > which leads to a syntax error during hdparm execution (e.g. hdparm > > force_spindown_time$VALUE instead of hdparm -S$VALUE). > > - Both options 'spindown_time' and 'force_spindown_time' are processed > > even if APM is not supported. From the comments in the configuration > > file (/etc/hdparm.conf), it is understood that 'spindown_time' will be > > applied for APM disks only and 'force_spindown_time' for all disks (or > > possibly for non-APM disks only). > > - The scripts will also apply hard-coded defaults for -S and -B if APM > > was detected. The hard-coded defaults differ from those used in > > /etc/apm/event.d/20hdparm, leading to inconsistent behavior. > > > > 4) Additional issues with non-APM disks: > > - Manually invoking hdparm -S$VALUE /dev/sdx is simply ignored even > > though hdparm executes successfully. The disks do not spin down after > > the time delay when there was no access. > > - Manually invoking hdparm -y /dev/sdx will spin down the disks > > immediately. The disks will not wake up unless they are accessed, which > > is the expected behavior. > > > > These were all working fine in hdparm 9.51+ds-1+deb9u1, which is the > > current version in stretch. > > > > In short, it is currently impossible to obtain a consistent and working > > configuration for non-APM disks. > > > > Many thanks and regards, > > Sebastien Behuret > > Hi Sebastien, > > 2. As APM is almost dead and most likely there are no laptops using APM > and buster. I'll drop /etc/apm/event.d/20hdparm in the next release. > > 3. This is a real issue. In /lib/hdparm/hdparm-functions I've left the > "force_spindown_time$VALUE" option intentionally, it need to be > translated to "-S" later in scripts using hdparm-functions like it is > done in 95hdparm-apm > > /lib/udev/hdparm is called by udev and need to be fixed. > > /usr/lib/pm-utils/power.d/95hdparm-apm called by pm-utils events and > takes care only about spin_down and apm options for the disks which > support apm. > > To obtain a consistent behavior /lib/udev/hdparm can call > /usr/lib/pm-utils/power.d/95hdparm-apm for spindown and apm options and > hdparm directly for all other options. > > 4. I failed to reproduce that. I couldn't put to standby a non-apm disk > on a stretch system with hdparm -S (hdparm 9.51) > Could you please try to build hdparm 9.51 or just get a binary package > and run it to see if 9.51 works for your disks compared to 9.58? > > Thank you for the detailed report. > Alex > > > > > > > > > > >
