Hi all

 

I consider myself a reasonably experienced UNRaid user and I have googled and read a lot of reddits and forum posts regarding similar issues, however, I've stumped myself and not sure what to investigate next.

 

My UNRaid box has been stable and reasonably regularly updated over the last couple of years without major issues. There have been few hardware changes but the latest (moved to a different case) occurred months before this issue began.

 

As the post title suggests, a couple of disks in my small array will randomly spin up, usually including parity, despite this no counter increases are observed under reads or writes. The open files plugin does not show any files on the array are open. My appdata, system and VMs live on cache only volumes.

 

As an experiment, I shutdown all my VMs and stopped all my containers. Manually spun down all drives, reset the counters and left the machine alone for several hours. Lo and behold the Parity and Disk 1 drives were spinning, yet reads/writes counters remained zero.

 

I know SMART read happens after spin up, but during this experiment SMART polling interval was set to 0.

 

There are no PCs or Macs running on my network at the moment, I am accessing UNRaid remotely (my servers) and no one else is home or on my home network

 

Diags attached, thoughts appreciated

unraid-diagnostics-20231026-1337.zip

Bump. Help?

See if anything changes if you get rid of cache_dirs (and reboot).  IMO I can't really tell the difference if it's installed or not anymore

I installed it in an attempt to resolve the problem 

Did you manage to fix this?

My parity drive keeps spinning up by itself with no activity on it for no reason and I am finding no solutions (tried posting a thread here too). 

Nope, nothing I’ve tried has resolved this for me. I’ve resorted to setting my parity and disk 1 drives to very long spin down timers (6 hours) in an attempt to minimise spin up/down cycles 

Well, I finally got to the stupid bottom of this, and it's ridiculously simple and even spelled out. I use SNMP to monitor unRaid, in the SNMP settings right at the top there's a setting called 'enable unsafe temperature checking', and under the help it says

 

Enable Unsafe Temperature Checking:

By default, this is disabled and SNMP only checks the disk temperature if the disk reports itself to be out of STANDBY mode. Some systems' disks always report STANDBY mode, preventing SNMP from ever fetching disk temperature. Enable this setting to use a less safe method of temperature fetching that may wake the disks from STANDBY in some systems.

 

In snmpd.conf, the following script is injected: /usr/local/emhttp/plugins/snmp/disk_temps.sh

 

Every time SNMP gets polled for disk temperature, this script is executed. Although the script attempts to check if the disk is in standby mode:

 

if [[ $smartctl_output == *"Device is in STANDBY mode"* ]]
        then
            echo "Disk $dev_path $disk_name in standby, reporting temperature as -2"
            # Append the formatted disk name and standby temperature to the cache file
            echo "$disk_name: -2" >> $cache_file_full_path

 

For whatever resason on my system smartctl does not return the stated 'Device is in STA...' therefore the script continues, spins up the disks and reports the temperature value - whether unsafe checking is enabled or not. What's really interesting, presumably because of some timeout value, the first time (after array spin down) the script runs, only parity spins up and one drive temp value is returned, the second time it runs, disk1 spins up, two values get returned, the third time, disk2 spins up.... etc etc

 

Case closed?