But how would you be able to pin this down to this default behavior specifically and not just drives dying on their own? It could cause drives to fail a few months earlier than if they were always operated properly, and you wouldn’t be able to conclusively blame it on the constant Emergency Unloads unless you set up 2 identical systems with that power off and on several times a day, with the only difference being that one has the workaround to power drives down properly and the other does not, and then compare if there is a significant difference in the lifespan of the drives.
Also, I am not sure this still applies to Dragonfish, but under Cobia, without managed start stop option set to 1, advanced power management doesn’t work either, which I think is also an issue perhaps worth addressing.
Yes, identifying longevity benefits and problems is difficult. The workaround helps people experiment.
Please set-up a test system and write it up… I’m sure others will be interested and we can jointly learn.
Will try!
Hmm, on Cobia, and, all mine are set to 0, yet, APM works. Perhaps drive model/manufacturer matters.
I run several file servers (not TrueNAS, just basic linux) and I have several hundred HDDs in production that look approximately like this:
Power_On_Hours 54070
Power_Cycle_Count 55
Power-Off_Retract_Count 2162
Load_Cycle_Count 2162
I’m fairly sure that Power-Off_Retract_Count increments anytime a drive goes to sleep.
It’s possible this parameter represents different stuff depending on a vendor or a different model. With my drive it does not increment if sleep is enabled for the drive.
A checkbox for this somewhere in the UI would be beneficial. I’m running a VM with the LSI HBA passed through and noticed that the drives didn’t shutdown when the VM shut down. Then when I shutdown the host, the drives sounded like I’d yanked the power cord instead of the usual sound they make when they are gracefully tuned off. Adding the init script commands fixes that.