Hard Disks do not spin down - QTS 4.2.2 Build 20161102

[mfratini]

Does someone know how to monitor and log the activity of daemon_mgr ?
I didn't and don't find a way to do that.
It seems that, on my NAS, killing the daemon_mgr then the disk activity is much less or close to zero.
Otherwise the disks are tickling every 2 seconds...
Reasonably one of the daemons monitored by daemon_mgr is failing and continuously restarted.

Does anyone have this NAS behavior?

[didbox]

... Otherwise the disks are tickling every 2 seconds...

Does anyone have this NAS behavior?

Hi,

Yes, same behaviour at my side, disks are tickling every 2 seconds...

[manny2003]

... Otherwise the disks are tickling every 2 seconds...

Does anyone have this NAS behavior?

Hi,

Yes, same behaviour at my side, disks are tickling every 2 seconds...

This is exactly what I have solved updating to release 20161214

[didbox]

I'm running release 4.2.3 Build 20170121 and obviously, it does not solve the problem...

[TomBlu]

This is exactly what I have solved updating to release 20161214

That was 4.2.2, so unless you don't care about this feature, you do not want to upgrade to 4.2.3. It's once again broken.

[manny2003]

This is exactly what I have solved updating to release 20161214

That was 4.2.2, so unless you don't care about this feature, you do not want to upgrade to 4.2.3. It's once again broken.

oh no! Again!

[mfratini]

... Otherwise the disks are tickling every 2 seconds...

Does anyone have this NAS behavior?

Hi,

Yes, same behaviour at my side, disks are tickling every 2 seconds...

This is exactly what I have solved updating to release 20161214

No. Unfortunately it didn't solve the issue for me.
Like I wrote in the past in this forum, the NAS started with this behavior after a power failure.
An old firmware upgrade (approximately in april/may 2016) fixed it. But I don't believe it has been an "intentional" fix.
Ineeded, with another power failure the issue appeared again and no other firmware upgrade has been able to fix it.
So that upgrade appears to have fixed the issue as a side effect... probably resetting the configuration of a daemon .. configuration which is now bad again.

Killing some daemons the NAS stops tickling or, at least, strongly reduce the number of disk accesses. (daemon_mgr, daemon_mgr.nvr, hal_daemon, bcclient).
Actually it is not clear what of these is causing the problem. Probably none of these because daemon_mgr is responsible of restarting failing daemons.
Probably one daemon is buggy or bad configured and keeps failing and restarting... or something like that.

The NAS also continuously respwan the "sleep" process with 1 second.
Writes the string "PD_Get_Slot_Name: can't retrieve SLOT_NAME!" once per minute in /var/log/hal_lib.log

In /var/log/storage_lib.log it contiuously (few seconds intervals) writes something like the follow:

md_get_status: /dev/md1 : status=0, progress=100.000000.
Blk_Dev_Get_Mount_Point: device "/dev/mapper/cachedev1" found, and mount point is "/share/CACHEDEV1_DATA".
Perform cmd "/bin/df -k /share/CACHEDEV1_DATA 2>>/dev/null | /usr/bin/tail -n1 | /bin/awk -F ' ' '{print $(NF-3)}'" OK, cmd_rsp=0, reason code:0.
Perform cmd "/bin/df -k /share/CACHEDEV1_DATA 2>>/dev/null | /usr/bin/tail -n1 | /bin/awk -F ' ' '{print $(NF-2)}'" OK, cmd_rsp=0, reason code:0.
md_get_status: /dev/md1 : status=0, progress=100.000000.
Blk_Dev_Get_Mount_Point: device "/dev/mapper/cachedev1" found, and mount point is "/share/CACHEDEV1_DATA".
Blk_Dev_Get_Mount_Point: device "/dev/mapper/cachedev1" found, and mount point is "/share/CACHEDEV1_DATA".
Blk_Dev_Get_Mount_Point: device "/dev/mapper/cachedev1" found, and mount point is "/share/CACHEDEV1_DATA".
Blk_Dev_Get_Mount_Point: device "/dev/mapper/cachedev1" found, and mount point is "/share/CACHEDEV1_DATA".

I know that those log files are in a RAM DISK but... probably all of these strings mean something.
I can't believe that it is impossible to have clean logs.

[runningnas]

Add me to the list of broken HDD suspend. It's broken since the 20161021 release and although reported via Helpdesk hasn't been fixed since.
I did run the blkdevmonitor script, but the output wasn't very meaningful to me, as the access listed there seemed to belong to some
software from QNAP itself. At least it didn't point to any well known application(s) that I would recognize.

[Anonymous_]

Add me to the list of broken HDD suspend. It's broken since the 20161021 release and although reported via Helpdesk hasn't been fixed since.
I did run the blkdevmonitor script, but the output wasn't very meaningful to me, as the access listed there seemed to belong to some
software from QNAP itself. At least it didn't point to any well known application(s) that I would recognize.

Not true. It was actually fixed in 4.2.2 build 20161214 (confirmed - fixed for me and others as well). But they (apparently) broke it in the latest (4.2.3 build 20170121) firmware again.

So if you want to have this fixed for sure, use 4.2.2 build 20161214.

[runningnas]

Not true. It was actually fixed in 4.2.2 build 20161214 (confirmed - fixed for me and others as well). But they (apparently) broke it in the latest (4.2.3 build 20170121) firmware again.

So if you want to have this fixed for sure, use 4.2.2 build 20161214.

It may have fixed it for some users, but for my model, at least for me, it didn't. I tried every firmware since it was broken and none of them restored the old behaviour.

[rmmeli]

Not true. It was actually fixed in 4.2.2 build 20161214 (confirmed - fixed for me and others as well). But they (apparently) broke it in the latest (4.2.3 build 20170121) firmware again.

So if you want to have this fixed for sure, use 4.2.2 build 20161214.

It may have fixed it for some users, but for my model, at least for me, it didn't. I tried every firmware since it was broken and none of them restored the old behaviour.

Same for me. I tried every firmware version since it was broken and none of them worked.

[didbox]

I'm running release 4.2.3 Build 20170121. For me, desactivation of QCenter solves the problem.

[iMactouch]

Why must hard disks spin down?

Because the TS-453A will consume 50W with four WD RED 4TB and "only" 20W when they are in sleep mode. The 20W ist still too much but better than 50W.

[P3R]

Because the TS-453A will consume 50W with four WD RED 4TB and "only" 20W when they are in sleep mode.

WD states the difference to be 4.1 W per disk so a total of 16.4 W with four disks.

Qnap specifications claims the difference is slightly less than WD, 13.49 W with unknown disk models.

I wonder who is lying here?

The 20W ist still too much...

20 W is an amazingly low power consumption for the convenience of having a very feature rich server capable of virtualization and 4*gigabit performance constantly available within seconds.

If you're not only trolling here and seriously trying to use less power, then sacrifice a little of that convenience and use the sleep mode or power off. That will make a real difference.

[iMactouch]

WD states the difference to be 4.1 W per disk[/url] so a total of 16.4 W with four disks.

Oh, sorry. This was not the correct value for the WD Red. This was the value for four Seagate 3TB drives with 7200 U/min.

20 W is an amazingly low power consumption for the convenience of having a very feature rich server capable of virtualization and 4*gigabit performance constantly available within seconds.

Ok. If you look from this side you are right.

If you're not only trolling here and seriously trying to use less power,

Why should i troll here?

then sacrifice a little of that convenience and use the sleep mode or power off. That will make a real difference.

Yes, in sleep mode the NAS is using only 1.7W. But to get the NAS into sleep mode is not so easy. To wake it up it is only a Wake on Lan which is done by many Apps on my Apple TV, but there is no App to bring it to sleep mode. For an iPhone you can use the App from QNAP but you need six taps to do it and this is not very easy for the kids.