HDDs spinning down earlier than configured standby time

[da-anda]

Hi, I'm not sure, but I think this issue arose in one of the last updates, since I hadn't noticed it before. I have some of my HDDs (which are on a rarely used pool) set to the following:

Code:

Disk Type: HDD
Transfer Mode: Auto
HDD Standby: 120
Adv. Power Management: 1
Enable S.M.A.R.T.: true
S.M.A.R.T. extra options:

so the disks should spin down after being idle for 120 minutes, but they spin down after being idle after a couple minutes instead. I tried to change the APM settings to others allowing spindown/standby (L 64, L 127), but this didn't fix the issue. Also changing the time to something higher didn't seem to fix it.

I check if disks are up by issuing hdparm -C /dev/sde, and they return "standby" a couple mins after I copied something to the pool.

Anybody any idea what might be going on or how to debug this? I am running TrueNAS-SCALE-22.02.3

 

[morganL]

Are we sure its not 120 seconds?

 

[Redcoat]

Manual says:

Power Management Settings​

Setting	Description
HDD Standby	Select a value from the dropdown list of options or leave set to the default Always On. This specifies the minutes of inactivity before the drive enters standby mode. This forum post describes identifying spun down drives. Temperature monitoring is disabled for standby disks.

So does the Help tip. Max selction in dropdown is 330.

 

[morganL]

Manual says:

Power Management Settings​

Setting	Description
HDD Standby	Select a value from the dropdown list of options or leave set to the default Always On. This specifies the minutes of inactivity before the drive enters standby mode. This forum post describes identifying spun down drives. Temperature monitoring is disabled for standby disks.

So does the Help tip. Max selction in dropdown is 330.

So is it bug on the documentation or the software?..... has anyone else set the timer and its worked as expected (minutes)?

This is an area that gets limited testing as we don't use it in iX products. Appreciate anyone verifying.

 

[da-anda]

what command does SCALE use in the background to set this value? If it is using hdparm -S, then the manual says

A value of zero means
"timeouts are disabled": the device will not automatically enter standby mode.
Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5
seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30
minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies
a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period
between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21
minutes plus 15 seconds. Note that some older drives may have very different
interpretations of these values.

So if SCALE is not converting the dropdown options to the correct respective value for hdparm, then the manual is wrong, otherwise is might be a bug. I'll try to set it directly via hdparm now and see what happens (hdparm -S 244 /dev/sde for 2h spindown).

 

[da-anda]

oddly, the disks still spun down now, and 2 h certainly haven't passed yet. No idea what's going on with my system.

 

[morganL]

oddly, the disks still spun down now, and 2 h certainly haven't passed yet. No idea what's going on with my system.

Getting some accurate time measurement would help diagnose.

If you have them, feel free to report a bug.

 

[likemandrake]

I note a similar problem to @da-anda, but in my case the HDDs go into standby after just 30 seconds of inactivity. I noticed the problem after some Angelfish upgrade. Today I upgraded to Bluefin and I have exactly the same problem. I should add that I have not changed anything in the settings since the upgrade to Bluefin.

In the "Power Management" settings for both drives I have set:
HDD Standby: "Always On"
Advanced Power Management: currently "Level 128", but I had "Level 1" before, only that I changed to a higher level when I noticed that my drives spin up very often, after a while of inactivity.

I think the key to the diagnosis may be the fact that my drives are connected to the OCU1 and OCU2 slots (OCuLink connectors), but they work as SATA drives, but the interface is PCIe/SAS. I checked with the command

Code:

blktrace /dev/sda -a PC -o - | blkparse -i -

what processes are accessing one of the drives, and it comes out that only kworker is doing so. Something I feel that my problem may have to do with the power management in Linux for PCI/PCIe devices, but I don't know how to get to the cause of this problem.

The path for the /dev/sda device in my case is this: "/devices/pci0000:00/0000:00:01.2/0000:20:00.0/0000:21:09.0/0000:2b:00.0/ata2/host1/target1:0:0/1:0:0:0/block/sda". I think there is a `power/` directory at every level of this path.