Dear Maintainer,
I recently upgraded to Jessie and after that my drives don't spindown automatically anymore. The -S option doesn't seem to work.
Using the -y option to spindown immediately works. And after that drives stay in standby so I don't believe there's any disk activity which prevents spindown.
I keep two of my disks, sdc and sdd, in standby most of the time and this used to work fine.
I tried reverting hdparm to stable version (9.39-1) and even oldstable (9.32-1) but that didn't help. It doesn't seem like an upstream problem either because the older versions don't work anymore event though they used to.
Both drives I try to spindown are similar:
ATA device, with non-removable media
Model Number: WDC WD30EZRX-00MMMB0
Serial Number: WD-WMAWZ0151867
Firmware Revision: 80.00A80
Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
I did find this bug report from Ubuntu which seems to describe the same issue:
https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1073137
Thanks,
Juho
Dear Maintainer,
* What led up to the situation?
Trying to set APM value on drives
* What exactly did you do (or not do) that was effective (or
ineffective)?
Edited hdparm.conf
* What was the outcome of this action?
All settings ignored/not applied
* What outcome did you expect instead?
Setting APM and write cache value
in Debian/testing currently hdparm still does not seem to work.
I already noticed this a while ago.
All settings (I) tried to be set are not set or not shown by hdparm afterwards.
Maybe hdparm could be updated, because two of my three drives are not getting
recognised still.
Sincerely,
Adrian Immanuel KIESS
Just wanted to mention this bug affects me as well. I have the same disks (WD30EZRX). As I found this bug report via google, it's not surprising we have the same hard disk, however. I can spin the disk down with 'hdparm -y /dev/sdd' and it stays spun down for hours. However, the disk will never spin down on its own, despite hdparm -S 2 /dev/sdd. Here's hoping someone finds a fix!
Stephen, I am also experiencing this bug. As a workaround, I added the following line to root's crontab file: hdparm -y /dev/sdb >/dev/null I tried using: "hdparm -S 12 -B 127 /dev/sdb" but "hdparm -C /dev/sdb" always reports the drive state is: active/idle. Regards, Kristjan
Stephen, As of yesterday, hard disk drive spin-down started working again. I do not think I changed anything manually for things to start working. As of now, I can no longer reproduce this bug. Regards, Kristjan
Stephen and others, After my last email, the bug returned; /dev/sdb stopped spinning down. A reboot seems to have fixed the problem. That is, after rebooting my computer, /dev/sdb spins down again. I suspect now that this bug is triggered by attaching a USB drive, but I have not tested this systematically. I noticed hdparm has a udev rule, /lib/udev/rules.d/85-hdparm.rules, but I don't yet understand what this rule does and if it could stop spindown. Regards, Kristjan
Dear Maintainer, since I did not see a confirmation of this bug since Jessie has bacome "stable", it might be appropriate to report that it still seems to be present. Since the time I upgraded from Wheezie to Jessie I experience the problems described in this bug. In detail: * The command "hdparm -S" has no effect. I tried time values from 1 to 244, none worked. However, the command "hdparm -y" works as intended. * The "spindown_time" option in /etc/hdparm.conf has no effect. The problem persists also when no partition of one of the disks is mounted. The used hard-discs are Model: "WDC WD30EZRX-00S" Model: "WDC WD10EADS-00L" Model: "WDC WD15EARS-00M" Everything worked fine with exactely the same hardware under Wheezie. I would appreciate a solution very much, since the bug is quite annoying. In the meanwhile, I also use "hdparm -y" with crontab as a (unsufficient) workaround. (Nevertheless: thanks to the maintainers for the good work!) Thanks, Olaf
Alohá, hard to believe this issue has not been solved for three years now and no plausible cause or even a usable workaround is to be found :-( After upgrading from wheezy to jessie a month ago I still cannot make 'hdparm -S' work, neither from bash nor via hdparm.conf (no problems with wheezy whatsoever). I've tried about everything in the book, all kinds of command formatting, addressing disks by classic /dev/sd<x>, by-id, by-uuid - to no effect at all.----------- Box setup: sda: SDD root / swap sdb: 500GB hdd for local sync activity sdc: 8GB flashdrive for nightly os backup sdd: 4TB hdd for LVM / NAS sde: 4TB hdd for LVM / NAS sdf: 4TB hdd for LVM / NAS sdg: 4TB hdd for LVM / NAS etc/fstab is set up via UUIDs----------- Currently my hdparm.conf contains a global spindown_time = 241 and a distinct one for every disk: spindown_time = 241 /dev/disk/by-id/ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E1YEDTPL { spindown_time = 241 } /dev/disk/by-id/ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0175547 { spindown_time = 241 } /dev/disk/by-id/ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0269155 { spindown_time = 241 } /dev/disk/by-id/ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0151053 { spindown_time = 241 } /dev/disk/by-id/ata-ST3500320NS_9QM0EPC7 { spindown_time = 241 } /var/log/syslog does show upon '/etc/init.d/hdparm reload': Apr 23 17:38:05 vault hdparm[12340]: Setting parameters of disc: Apr 23 17:38:05 vault hdparm[12340]: /dev/sdg: Apr 23 17:38:05 vault hdparm[12340]: setting standby to 241 (30 minutes) Apr 23 17:38:05 vault hdparm[12340]: /dev/sdg. Apr 23 17:38:05 vault hdparm[12340]: /dev/sdf: Apr 23 17:38:05 vault hdparm[12340]: setting standby to 241 (30 minutes) Apr 23 17:38:05 vault hdparm[12340]: /dev/sdf. Apr 23 17:38:06 vault hdparm[12340]: /dev/sdd: Apr 23 17:38:06 vault hdparm[12340]: setting standby to 241 (30 minutes) Apr 23 17:38:06 vault hdparm[12340]: /dev/sdd. Apr 23 17:38:07 vault hdparm[12340]: /dev/sde: Apr 23 17:38:07 vault hdparm[12340]: setting standby to 241 (30 minutes) Apr 23 17:38:07 vault hdparm[12340]: /dev/sde. Apr 23 17:38:07 vault hdparm[12340]: /dev/sdb: Apr 23 17:38:07 vault hdparm[12340]: setting standby to 241 (30 minutes) Apr 23 17:38:07 vault hdparm[12340]: /dev/sdb. Apr 23 17:38:07 vault hdparm[12340]: /dev/sdb /dev/sdd /dev/sde /dev/sdf /dev/sdg . This looks good actually. Also issuing 'hdparm -y' from bash works right away and the disks do not wake up by themselves afterwards unless accessed. So no daemons et al. seem to be the culprit (i.e. Samba 4). When Samba reads a file the LVM actually only wakes up the disk that file resides on. Is there any workaround that is remotely working the "debian way"? I've tried a crontab applying 'hdparm -y' but that actually wakes a sleeping disk up before sending it back to sleep and even if encased in a hdparm test for active / idle state of the respective disk this solution is quite annoying if You're streaming media from that very disk while sending it to sleep - as streaming connections usually read in bursts of buffer-fills the disk will be idle often enough to let the tests succeed). Solutions via lsof <mountpoint> don't work properly either since there is nearly always some smb client filehandle open to the share itself even when there is no smb activity (which didn't matter with Wheezy). Maybe I can limit this to actual files being opened instead of just mount points/folders. Does anybody have a usable workaround? When will this issue be fixed? thanks & regards, Martin
Not sure if somebody of the bug reporters is affected by this as well, but I found yesterday that a wrong advance power manangement level can prevent spindowns:
-B Get/set Advanced Power Management feature, if the drive supports it. A low value means aggressive power management and a high value means
better performance. Possible settings range from values 1 through 127 (which permit spin-down), and values 128 through 254 (which do not
permit spin-down). The highest degree of power management is attained with a setting of 1, and the highest I/O performance with a setting
of 254. A value of 255 tells hdparm to disable Advanced Power Management altogether on the drive (not all drives support disabling it, but
most do).
root@Silberkiste:~# hdparm -I /dev/sdb|grep level
Advanced power management level: 254
root@Silberkiste:~# /etc/init.d/hdparm restart
[ ok ] Restarting hdparm (via systemctl): hdparm.service.
root@Silberkiste:~# hdparm -I /dev/sdb|grep level
Advanced power management level: 64
root@Silberkiste:~#
Kind regards
Rainer
Dear Customer, Your item has arrived at January 24, but our courier was not able to deliver the parcel. You can find more details in this e-mail attachment! Warm regards, Milton Buckley, USPS Mail Delivery Clerk.
I am having the same problem with the following drive: ATA device, with non-removable media Model Number: WDC WD10SPZX-00Z10T0 Serial Number: WD-WX21E370JZH3 Firmware Revision: 01.01A01 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0 Is it possible that some drives simply don't support such automatic spindown, and expect the OS to handle that? Kind regards, Ralf
Some drives such as WD Green ones handle APM and spin down differently and don't work with hdparm. You may have more luck with idle3-tools, but no idea if this tool is applicable to WD Blue disks. It's rather the disk firmware and not the OS handles the spindown in this case. So I think in general it's better to avoid disks using exotic features. [0] https://superuser.com/questions/555400/what-do-different-values-of-hard-drives-advanced-power-management-feature-hdpa/558622#558622 [1] https://community.wd.com/t/wd-blue-mobile-spins-down-too-early-or-not-at-all-and-ignores-spindown-time-settings/17628 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880008#10
Hi, I tried both -B 127 and -B 255, that made no difference. Kind regards, Ralf
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