On Fri, Jun 28, 2019 at 10:40 AM Alex Mestiashvili <ames...@rsh2.donotuse.de> 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 239) Using previous versions of hdparm (which used to work) did not solve the issue, so it is unlikely that hdparm is the actual cause. > > > 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? > I've never timed the actual spindown delay, hdparm states the 'human delay' after issuing -S (e.g. -S248 gives 4 hours) and it has always seemed right to me. It is true that the actual delay may be vendor-specific, and some drives may not support all delays. The disks will not wake up after invoking hdparm -y manually, thus eliminating the possibility that system noise prevented automatic spindown. > 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 ? > Some drives may not support short delays IIRC. 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. > Not sure about that. In previous versions, hdparm would attempt to set -B254 (128 on battery) on all drives but would fail if APM was not supported. Do you know if there are any other options that could affect automatic 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 > Thank you for suggesting hd-idle. At this stage it would be great if somebody could confirm if they successfully achieved automatic spindown (hdparm -S, spindown_time, force_spindown_time) in a recent buster/testing system. > Best, > Alex > Best regards, Sebastien
