On 6/30/19 2:31 PM, Alex Mestiashvili wrote: > On 3/10/19 10:41 PM, Stijn Segers wrote: >> Hi, >> >> I recently experienced the same issue here. Until Debian Stretch everything >> was fine, but I recently upgraded to Debian Buster (pre-release). I >> previously just set the spindown time and this used to work fine. Hdparm -Y >> on the devices (using the plain /dev/sd? paths) still worked, but automatic >> spindown was somehow broken. I tried enabling APM (setting it to 127) but >> that didn't change a thing - I previously only set spindown time and that >> worked just fine. I then switched to /dev/disk/by-id/ paths, that didn't >> work either. >> >> What I have noticed, however, is that spindown_time settings up to 59 work; >> anything from 60 (5 minutes) and up won't. Hope this helps. >> >> Cheers >> >> Stijn >> > > Hi, > I just have managed to set the spindown for apm 60 and 100. Both worked. > There is a trick though. After setting the spindown_time (-S) one > actually need to run hdparm -C /dev/sdX twice as the very first time > hdparm -C returns an old value for the disk - active/idle, but the > second time it returns that the drive is in standby mode. > > Also there are no APM related changes as far as I see in the code > diff[0] between hdparm 9.51 in Stretch and 9.58 in Buster. What have > also changed is udev and kernel versions. > One can try to test a stretch machine where all presumably worked and > update hdparm and then udev (available via stretch-backports) to nail > down the problem. > > Best, > Alex > > [0] > https://salsa.debian.org/debian/hdparm/compare/debian%2F9.51+ds-1...upstream%2F9.58+ds > The problem is most likely caused by smartd or udisksd which poll drives regularly. Please see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930796#42
