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
