HDD Spindown Timer 2.2.0

This resource was originally created by user: ngandrass on the TrueNAS Community Forums Archive. Please DM this account or comment in this thread to claim it.

Disk spindown has always been an issue for various TrueNAS / FreeNAS users. This script utilizes iostat to detect I/O operations (reads, writes) on each disk. If a disk was neither read nor written for a given period of time, it is considered idle and is spun down.

Periodic reads of S.M.A.R.T. data performed by the smartctl service are excluded. This allows users to have S.M.A.R.T. reporting enabled while still being able to automatically spin down disks. The script moreover is immune to the periodic disk temperature reads in newer versions of TrueNAS.

Key Features​

  • Periodic S.M.A.R.T. reads do not reset the disk idle timers
  • Configurable idle timeout and poll interval
  • Support for ATA and SCSI devices
  • Works with both TrueNAS Core and TrueNAS SCALE
  • Per-disk idle timer / Independent spindown
  • Automatic detection or explicit listing of drives to monitor
  • Ignoring of specific drives (e.g. SSD with system dataset)
  • Executable via Tasks as Post-Init Script, configurable via TrueNAS GUI
  • Allows script placement on encrypted pool
  • Optional shutdown after configurable idle time

For more information, installation and usage instructions as well as the most recent release, checkout the repository on GitHub: GitHub - ngandrass/truenas-spindown-timer: Monitors drive I/O and forces HDD spindown after a given idle period. Resistant to S.M.A.R.T. reads.

1 Like

Dear TrueNas Community, dear @iX_Resources or ngandrass.

I’m running TrueNAS-SCALE-23.10.2 as a VM on Proxmox 8.1.4 where NVMEs and HDDs are mounted to the TrueNas Scale Installation as scsi Hard Disks with their respective device id.

following the instructions I get a lot of SG_IO: bad/missing sense data errors
SMART Values are not available at truenas scale level.

root@truenas-scale-vm:/home/admin/spindown_timer# ./spindown_timer.sh -d -c -t 10 -p 5 -u zpool -i boot-pool
[2024-04-16 13:43:32] Performing a dry run...
[2024-04-16 13:43:32] Monitoring drives with a timeout of 10 seconds: sdb sdc sdd sde sdf
[2024-04-16 13:43:32] I/O check sample period: 5 sec
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[2024-04-16 13:43:32] Drive power states: [sdb] => 0 [sdc] => 0 [sdd] => 0 [sde] => 0 [sdf] => 0

I followed the instructions in setting power states on the storage devices,
does the script not work with scsi deviced rootet to truenas scale as a VM on hypervisors?

with regards

Unfortunately, passing drives from Proxmox in this way will not allow TrueNAS direct access to the drives. The problems you are having are expected in that configuration, and it is recommended you use PCI-Express pass-thru of a supported HBA like this one:
LSI SAS 9211-8i PCI Express to 6Gb/s Serial Attached SCSI (SAS) Host Bus Adapter User Guide (broadcom.com)

Please see:
Resource - “Absolutely must virtualize TrueNAS!” … a guide to not completely losing your data. | TrueNAS Community

3 Likes

Can someone please explain why is this even needed in the first place? I see power saving options in TrueNAS Scale UI, I can seet the spindown time the Advanced Power Management levels configurable.

I think it goes without saying that optimizing power consumption in NAS setups is fairly crucial aspect of running them. So despite these options in the UI and TrueNAS seemingly supporting Power Management, these actually don’t work? Then why even provide these options at all, misleading users?

If “Disk spindown has always been an issue”, why don’t you make it a priority and fix it internally, not brush it off to a third-party script? If a script can fix it, surely you have resources to fix that natively?

On top of that, the script items doesn’t seem to be tested well with recent versions. Not to mention running a community script for handling hardware on a NAS — where stability and your data resilience is of upmost importance — is not something anyone should be doing, with all respect to the script’s author(s).

At the very least you could have opened a JIRA item tracking the effort to mitigate those issues and have them linked it here, offering that script as an interim solution.

Just purely from a high level in general, I personally think this script (and many others like it!) increases the risk of failure, even more so than the “normal” power-saving features you can enable with the check box. Many others share this opinion, and there is data to support it.

For a homelab usecase, this script has a place. That’s probably why it’s here and why the good work of the author is pinned even though I assume he’s not re-registered since the forum migrated. It does what it says it does and you will reduce power consumption to a degree (in certain situations only). But that doesn’t mean I think you should.

Encouraging your drives to park their heads over and over again has a cost. Spin-down, park, start-up, spin-up… It takes time, and those load and unload cycles wear the bearings and other wear items faster. I know flash storage has been mainstream for a long time now, but let’s not forget the first principles here.

A hard drive is a mechanical device and it has wear components. Running drives constantly vs load cycling, will generally wear those components far less.

In fact, there was much discussion about this back in the old forums…and apparently 10 years ago! The WD Green story was quite the ghost of christmas past. Gawsh I’m getting old lol.
Hacking WD Greens (and Reds) with WDIDLE3.exe | TrueNAS Community

In that case, one of the original FreeNAS moderators did a really good writeup explaining the dangers of drives that natively do what this script attempts to emulate. TLDR; Misleading advertisements/marketing driven/crummy product.

This is from Western Digital, explaining what the SMART value means

Load Cycle Count or Load/Unload Cycle Count

Some laptop drives and “green power” desktop drives are programmed to unload the heads whenever there has not been any activity for a short period, to save power. Operating systems often access the file system a few times a minute in the background,causing 100 or more load cycles per hour if the heads unload: the load cycle rating may be exceeded in less than a year.There are programs for most operating systems that disable the Advance Power Management (APM) and Automatic acoustic management (AAM) features causing frequent load cycles.

To be clear, the script we are talking about will produce the behavior in this sentence

Operating systems often access the file system a few times a minute in the background,causing 100 or more load cycles per hour if the heads unload: the load cycle rating may be exceeded in less than a year.

The script effectively over-rides any normal driver power saving features (and their included safety nets). You can learn more by researching the ones WD references:

.There are programs for most operating systems that disable the Advance Power Management (APM) and Automatic acoustic management (AAM) features causing frequent load cycles.

One final thought, depending on your workload, there’s a very real possibility that this script could actually increase power consumption. If you irregularly access the NAS at random times in the day, you’ll be tripping the “fuse” more often. Hard drive spin-up uses far more energy than during run-time operations.

To quote from the linked resource

Normally, a functioning hard drive’s head does not touch the platters at all. It floats on a cushion of air generated from the rapidly spinning media and allows the head to float at about 3nm from the platter. When a disk is spun down this cushion of air does not exist, so the head is placed in a location that will not potentially damage the data. The necessary tolerances if blown up to the macroscopic world would be like flying a commercial airplane 5 inches off the ground and staying within 1mm at all times. Pretty amazing that drives are able to perform reliably under such conditions for months or years, huh? Anyway, because the head rides on this cushion of air, it increases drag on the platters. This means that the motor will have to spend more energy to keep the platters moving at the same speed. This increases the power needed as well as increases heat produced.

Enough start-ups you’ll make the break even point (in power consumption, thus in $), and you’ve worn you hard drive for no reason. Even more start-ups, you’ve actually drawn more power than you would have in normal operation.

Fun fact: Many disk shelves and servers intentionally power drives up in batches instead of all at once when the power to the chassis they are in is cycled. If they didn’t power stagger, the load could potentially trip a breaker because the surge amperage is so high.

1 Like