Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
Hi Alex, Apologies for the late reply, I found what prevented the HDDs to enter standby mode: udisksd. I leave the workarounds here for reference. Intro: The smartd and udisksd [1] daemons poll S.M.A.R.T. data from drives regularly, and HDDs with a longer standby (or spindown) timeout than the polling interval may fail to enter standby. In the case of udisksd, drives that are already spun down are usually not affected, and standby timeout applied by udisks2 seems to be unaffected. Workarounds for smartd: - Add -i value/--interval=value option to smartd_opts in /etc/default/smartmontools, using a value greater than the standby timeout. - Add -n standby or -n standby,q to DEVICESCAN statement in /etc/smartd.conf to prevent checking disks in standby, and further suppress log message to that effect so as not to cause a write to disk. Workaround for udisksd: - Run systemctl mask udisks2 to prevent udisksd execution. Other possible workarounds could be setting the standby timeout to a duration lower than the default polling interval (1800 seconds for smartd, 10 minutes for udisksd), forcing a manual spindown using hdparm -y /dev/sdx, or trying hd-idle as suggested earlier in this thread. Best regards, Sebastien [1] https://wiki.archlinux.org/index.php/Udisks#Broken_standby_timer_(udisks2) On Wed, Oct 9, 2019 at 7:58 AM Alex Mestiashvili wrote: > > > On 7/1/19 1:23 PM, Sébastien Béhuret wrote: > > 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. > > > > > > I was unaware of this bug and never experienced this issue with > > external USB drives. I do remember external USB drives going into > > standby mode shortly after backup completion, but this does not > > occur anymore in debian buster/testing. The drives in question do > > not support APM so it makes sense given that -S36 is no longer > > applied in this case. > > > > > > Correction: The external USB drives that used to go into standby mode > > were not getting any hdparm settings (not event -S36) as they were not > > used on battery mode and spindown feature is disabled by default for USB > > drives in recent hdparm versions. This must have been an internal > > feature from WD as documented here: > > https://support-en.wd.com/app/answers/detail/a_id/16047 > > > > The fact that automatic spindown does not work anymore for these drives > > in buster/testing may indicate that there is some form of system noise > > (but somehow this noise would not be sufficient to wake up the drives > > after hdparm -y) or that something else is actively disabling automatic > > spindown. > > Hi Sébastien, > > I still have no solution for hdparm, but as workaround one can try > hd-idle which is now available via buster-backports or testing. > > Best regards, > Alex >
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
On 7/1/19 1:23 PM, Sébastien Béhuret wrote: > 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. > > > I was unaware of this bug and never experienced this issue with > external USB drives. I do remember external USB drives going into > standby mode shortly after backup completion, but this does not > occur anymore in debian buster/testing. The drives in question do > not support APM so it makes sense given that -S36 is no longer > applied in this case. > > > Correction: The external USB drives that used to go into standby mode > were not getting any hdparm settings (not event -S36) as they were not > used on battery mode and spindown feature is disabled by default for USB > drives in recent hdparm versions. This must have been an internal > feature from WD as documented here: > https://support-en.wd.com/app/answers/detail/a_id/16047 > > The fact that automatic spindown does not work anymore for these drives > in buster/testing may indicate that there is some form of system noise > (but somehow this noise would not be sufficient to wake up the drives > after hdparm -y) or that something else is actively disabling automatic > spindown. Hi Sébastien, I still have no solution for hdparm, but as workaround one can try hd-idle which is now available via buster-backports or testing. Best regards, Alex
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
> > 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. >> > > I was unaware of this bug and never experienced this issue with external > USB drives. I do remember external USB drives going into standby mode > shortly after backup completion, but this does not occur anymore in debian > buster/testing. The drives in question do not support APM so it makes sense > given that -S36 is no longer applied in this case. > Correction: The external USB drives that used to go into standby mode were not getting any hdparm settings (not event -S36) as they were not used on battery mode and spindown feature is disabled by default for USB drives in recent hdparm versions. This must have been an internal feature from WD as documented here: https://support-en.wd.com/app/answers/detail/a_id/16047 The fact that automatic spindown does not work anymore for these drives in buster/testing may indicate that there is some form of system noise (but somehow this noise would not be sufficient to wake up the drives after hdparm -y) or that something else is actively disabling automatic spindown.
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
On Fri, Jun 28, 2019 at 10:40 AM Alex Mestiashvili wrote: > > 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 > The updated script looks just right with -B and -S options going through 95hdparm-apm and other options applied locally. Thanks! > 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 > This is great default behavior. Calling 95hdparm-apm from /lib/udev/hdparm also prevents setting options that laptop-mode-tools would normally handle. > 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. > I was unaware of this bug and never experienced this issue with external USB drives. I do remember external USB drives going into standby mode shortly after backup completion, but this does not occur anymore in debian buster/testing. The drives in question do not support APM so it makes sense given that -S36 is no longer applied in this case. > > > 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. :) > The logic that you described above is just fine and you are absolutely right that it is unlikely hdparm-functions is/will be used for custom scripts. If the force_spindown_time hack was implemented in hdparm-functions, it would also be necessary to detect laptop-mode-tools and parse its configuration there, making things a little trickier. > > > > 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. > You are right, unfortunately I won't be able to make this test now. I'm confident that hdparm -S is somehow broken is recent buster debian due to: - Multiple drives affected by the issue (internal and USB external) - These drives will spin down successfully with hdparm -y, and will stay in standby mode unless manually accessed (tested for over 48 hours) - hdparm -S runs successfully but none of the delays work (tested delays ranged from a few seconds to a few hours) - It had been working flawlessly with this hardware running debian testing up to Fall 2018 (hdparm 9.56, kernel 4.17, udev
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
> 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
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
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 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. > > > >
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
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
Bug#930796: spindown_time and force_spindown_time are broken in hdparm 9.58+ds-1
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
