Support HDD standby

Feature Requests
21

My 2 cents.

Many enterprise/datacenter HDDs have “hidden” power modes that can be triggered by specific APM values or obscure smartctl commands. I’ve found that just setting the proper APM mode on my HC550s, they can enter a sort of “standby” where my entire system drops from 120w to 100w for a 6 disks array. There are many more modes with a sort of spin down from 7200 to 5400 rpm that works with the above mentioned obscure smartctl commands. You can find almost anything in the HDD manual and AI can give — with some trials and errors — some commands to try too.

22

It looks like they don’t care about us or our need to spin down disks. I don’t like that I have to apply patches to the OS just to make a fundamental homelab feature work. Sooner or later, I’ll need to update for security reasons anyway. If there’s still no fix by then, I’ll have to switch to another solution.

Hello Unraid or OMV…

Even though I’ve been very happy with TrueNAS so far and really like it. Power consumption is one topic… the other is heat. Especially in a small rack, where disks run all the time even when they aren’t being used for days.

The Jira ticket is still open but not assigned, even for such a small fix. It makes me think there may never be a solution… at least not in the near future.

23

It’s a shame standby was actively broken with one of the recent versions since it still works, but the new SMART monitoring system causes the drive to wake up every few minutes.

The people arguing that spindown is ‘bad’ don’t consider the case of a backup pool being rarely used, in my case once a day. I dont need it spinning for 99% of the day yet with these changes I have to have it on 24/7 to get a proper 321 backup.

24

My NAS is all SSD apart from a HDD which is used once a week in a scheduled ZFS replication. I’ve set the spindown in the UI to 5 minutes but it still periodically wakes during the day.

Having a “spindown” button that is actually useless as it will be spun back up again to check the drive temperature (of a spundown disk, so not relevant) is pretty sad.

25

Two thoughts. First: the so-called podcast is good for complex topics and directional clues.

Second: if I had an infrequent backup or replication schedule on my desktop system, I wouldn’t hope the OS spins down the target volumes. Hope that it leaves them alone despite other triggers such as indexing, searching, etc.

Instead, I would explicitly unmount those volumes when I want them inactive. And explicitly mount them again when I expect them to be active.

For ZFS, you’d do that at the pool level. In TrueNAS, via pool export and import_pool jobs.

But if anyone’s actually serious about spinning down between weekly or daily backup tasks, then energy usage is only one piece of that puzzle. There’s also the security principle of not leaving those disks out unnecessarily. Spin-up cycles be darned: shut down and take the backup out of play until the scheduled cold boot and backup operation — as with a time-lock safe.

26

However, if you try to do this in Truenas 25.10+, it still would not let you spin down the disks due to thermal monitoring accessing even unmounted pools and blocking them from spindown.

On top of this, it is quite complex to write a script that automatically unmounts a pool after all Truenas replication jobs are finished, mounts them for scrubs etc - just to spin down idle disks, a feature that used to work a expected up to Truenas 25.04.

27

Are you saying people should physically disconnect drives that are only used occasionally? All of your options are more complicated than using the feature that worked perfectly fine before 25.10, and still exists in the UI, just is overridden by the new monitoring system. We just want a forgotten optional feature to be supported again.

28

Huh. TIL. Thanks!

On the security principle, discussing weekly replications: yes it is good practice to airgap your last resort backup. The target repo should pull only, refuse incoming connections, and remain out of reach of potentially tainted renegade source hosts.

This shouldn’t sound complicated. Power-on; perform transfer; shut down.

Mind you, that’s not something that you’d look to a NAS appliance to tackle. NAS appliances have other mandates which could very well undercut this specific use case.

29

No it doesnt sound complicated it sounds cumbersome compared to what used to work. It sounds nice until you realise we dont all have 3 separate NAS devices like you have. I use my one and only NAS for both storage and backup on separate pools.
My backup pool is only used by truenas for a copy of some datasets, within the same device, from one pool to another. I shouldnt have to set up a second machine for this.

30

Copy to another pool is better than no backup at all, but having the backup in the same machine means that a single disaster (rogue PSU / fire / burglar…) can take both your data and the backup in one strike. So for better security you really should consider a second NAS.

31

:100: and I’d emphasize also remote breach/ransomware.

To be clear: periodic backup was only one argument presented in support of spinning down drives. But given that context, it is worth noting that backup drives are exposed even when spun down.

32

There is also tiered very infrequent accessed data (archival) that needs to stay “hot”.. well with spindown we could call it “lukewarm”. I see no practical need to keep disks spinning that would be accessed perhaps once a year when Karen from finance needs some PDF from 17 years ago. However I do need to know that the server is up and patched (cant shut it down).

33

I have multiple TrueNAS 25.10.4 systems that are used almost exclusively as backup targets. For years I’ve configured the HDDs to enter standby after 10 minutes of inactivity.

After upgrading, I noticed the drives were waking up roughly every 90 minutes. Looking through the middleware source, I found the SMART alert source is scheduled with:

schedule = IntervalSchedule(timedelta(minutes=90))

in:

/usr/lib/python3/dist-packages/middlewared/alert/source/smart.py

On my systems (WD Red and Seagate Exos drives), increasing this interval appears to prevent the frequent wakeups. I changed it to:

schedule = IntervalSchedule(timedelta(minutes=720))

Because the TrueNAS root filesystem is read-only, I used a bind mount override instead of modifying the installed file directly.

Copy the original smart.py to a persistent location (I used /root/smart.py).
Modify the schedule value in the copied file.
Add the following Post Init command in the TrueNAS UI:
mount --bind /root/smart.py /usr/lib/python3/dist-packages/middlewared/alert/source/smart.py && sleep 60 && systemctl restart middlewared

After implementing this, my backup-target systems now wake the data drives only:

Twice per day for the SMART alert checks (12-hour interval)
Once per day for the backup job
Occasionally for scrubs and scheduled SMART tests

For my use case, roughly 3–5 spin-ups per day is preferable to drives waking every 90 minutes.

A few notes:

This is an unsupported workaround and may stop working after updates.
I have only tested this on TrueNAS 25.10.4.
I have not tested whether there are any side effects beyond reducing disk wakeups.
Use at your own risk.

One interesting observation: on both the WD Red and Seagate Exos drives, temperature reporting continues to update through the kernel hwmon interface even while the drives remain in standby. I verified with smartctl -n standby that reading those temperatures does not wake the disks.

I’m far from an expert when it comes to this kind of tinkering, so if there is a reason this approach is considered a bad idea, I’d appreciate any feedback. Also, this is just a small one-person home lab, so my goals and risk tolerance may be very different from production or enterprise deployments.

34

Hi,

I just wanted to provide my support for this feature request. While I understand that spinning down disks might not be recommended in many (most?) use cases, it is a feature that can benefit lots of people while not affecting the default behavior for the rest.
In my particular case, the main concern is noise, since I have the NAS in my apartment living room. Energy usage is also noticeable in the electricity bill. Only having 5 to 10 spinups each week, I am pretty sure that the wear and tear in the disks is not something to be concerned.

35

I think this is an important feature for home users, when they access their NAS occasionally.

In my case, lack of spindown, more than doubles my power consumption.

I wonder how this affects HexOS?
It is a significant disadvantage compared to Unraid, and a ton of new NAS systems.

36

@TrueNas Developer: PLEASE! bring the HDD Standby back!

a lot of home users have built der NAS for such use-cases like rare HDD access and low power/noise setup. Also this “little” home users provide feedback you use for your enterprise customers.
So please don’t kick them out for such a small and simple function like “deactivate Background SMART Tests” or an option to change the interval.

A small change and you would make so much people from the community to stay with TrueNAS instead of changing back to other solutions. :folded_hands: :pleading_face:

37

Don’t forget to vote!

(No guarantee that the request will not be eventually rejected as not aligning with the roadmap but then you’ll know why you’re changing for another solution.)