WD Digital Red does not spin down with hdparm -y

[AntonyDu92]

Hello,
I have a TS119 with, both recently : firmware 4.2.4 + WD Red 4To Nasware 3.0.
I haven't seen my Hard disk spin down (which light off the "hdd" led), whereas i have seen it often with my old conf (firmware 3.8.3, a 2To disk Samsung if i remenber).
To test this, i use a "known" script blkdevMonitor.sh which use among other the "hdparm -y" command.
When good conditions are there, this script shows that nothing use the disk, that it could spindown. But it does not.
The probable explanation i have found is this : http://withblue.ink/2016/07/15/what-i-l ... e-nas.html
"
On Linux, the traditional way to control disk standby (and power management) is to use hdparm; however, hdparm will not work with WD Red drives, because the firmware of the disks doesn’t support that. Instead, we can use the third-party hd-idle utility to accomplish this.
"
Disappointed !
As QNAP Linux is not standard, i don't think it will be easy for me to compile hd-idle..

If somebody could help..
Thank you

[schumaku]

There is no need to build any utilities. WD Red can spin-down like any other HDD in a QNAP NAS - if the system is permitting. QNAP does not use the hdpram utility to spin-down the HDD on it's built in detection mechanism. I can be wrong - but it does not relevant if hdparm -y does effectively spin-down the HDD, the point is that it has to go to standby mode.

The output of the blkdev test does not show anything but the time stamps, as shown below?

[/share/Public] # ./blkdevMonitor_20151225.sh
===== Welcome to use blkdevMonitor_v2 on Wed Apr 12 11:00:37 CEST 2017 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1
Start...
============= 0/100 test, Wed Apr 12 11:01:10 CEST 2017 ===============

============= 1/100 test, Wed Apr 12 11:02:01 CEST 2017 ===============

============= 2/100 test, Wed Apr 12 11:02:30 CEST 2017 ===============

============= 3/100 test, Wed Apr 12 11:02:55 CEST 2017 ===============

....

Quick test ... /dev/sde is a WD Red 4TB, NASware 3, ...

[~] # /sbin/hdparm -y /dev/sde

/dev/sde:
issuing standby command
setting standby immediately.
[~] # /sbin/hdparm -C /dev/sde

/dev/sde:
drive state is: standby
[~] # /sbin/hdparm -C /dev/sde

/dev/sde:
drive state is: active/idle

The rationale for developing the hd-idle tool (which is much older than any WD Red) was that external USB IDE HDD were not spin down. WD REd were introduced in June 2012 - and amazingly WD failed two times initially on the first as well as on into of the NASware 3 WD Red (ie. the early manufactured 4 TB ones).

Disappointed? Well, again ... any kind of bugs are possible. Happens everywhere.

Beyond, I won't go into another sense or nonsense discussion of HDD spin-down. Fact is that some legacy systems we're operating have 24*7 spinning for >25 years, some on 5400, some on 7200 RPM ... while the first "modern" Flash based replacement products already started failing in the first 18 months.

[storageman]

But Qnap don't exactly make it easy to find out what app is preventing spin down.
I guess the issue will disappear when we're all on SSDs.

[AntonyDu92]

Hello @schumaku,

I have an older version of blkdevMonitor.
It only writes this :
"Countdown:10 9 8 7 6 5 4 3 2 1
Turn on block_dump
Clean old dmesg
Start...
"
Then this periodicaly :
"/dev/sda:
issuing standby command
setting standby immediately.
/dev/sdb: No such device or address
/dev/sdc: No such device or address
/dev/sdd: No such device or address
/dev/sde: No such device or address
Countdown: 10 9 8 7 6 5 4 3 2 1
"

Could you give me your more recent version ?

Thank you

[schumaku]

There is a cloud link in the Wiki ... I don't really like the idea -> https://wiki.qnap.com/wiki/Hard_drives_spindown_issues

[AntonyDu92]

Thank you @schumaku,
I have run the test, and a lot of process are displayed..
md9_raid1(557): WRITE block xxxxx on sda (8 sectors) (more often)
flush-9:9(7778): WRITE block 262464 on md9 (8 sectors)
kjournald(1681): WRITE block 536024 on md9 (8 sectors)
ip_filter(9433): dirtied inode 6718 (ipsec_allow.conf) on md9
jbd2/sda3-8(2113): WRITE block xxxx on sda (8 sectors)
For the time being, i don't explain everything, but surely it comes from my recent change of firmware.
The things i have probably unset in my old firmware are set again, and probably other things are added with the new 4.2.4 firmware that i am not aware of.
About jdb2 on sda3 : my sda3 is type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,noacl) : there is no "noatime". Adding noatime could avoid jdb2 journaling ?