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 <ames...@rsh2.donotuse.de> 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 >
