I am a bit of a noob with Unraid, so I apologize if I don't describe everything correctly. My server diagnostics are here:

server02-diagnostics-20230915-1422.zip

 

I am running Unraid 6.12.3, and I'm having an issue where file access on an SMB share is causing the disks to spin-up in the array when they shouldn't. It is happening with multiple shares, but I included an example in the screenshots. The share is set to use the cache first, then move to array. But when I access it via SMB on another windows computer, it will work, but it spins up the disks when filed in the share are edited. 

 

I cannot figure out why the disks are being spun up here. When I check the files on the disk itself, they are not modified. It still contains the old version, as mover has not yet been run. The modification is present in the cache drive as expected.

 

Is there any way to change this so the disks stop being spun up? I thought that the share being cache first would mean that all activity would happen on the cache drives, and never touch the array until mover is called. So far this is negating a lot of power reduction I am trying to accomplish by spinning down disks. This happens for other shares as well, including, very annoyingly, my backup share where I have windows file history backups, set up following SpaceInvaderOne's video. This means that almost when I do anything on my desktop, it will inevitably spin up the relevant disk and parity disk.

Did you edit these diagnostics? The syslog lines you obscured do not appear in them, but the screenshot shows the files on disk2

Ah no, I didn't edit them, but I made the diagnostic log a little while after I made the screenshots of the syslog. 

And yeah, I don't understand why it shows on disk2. When I browse into disk2, it does not show the files having been updated. That only shows when I browse to the cache. But yeah, the File Activity log shows that disk2 was accessed. I cannot understand why though.

Also, those lines in the screenshot with file names are not syslog, they are from the File Activity plugin. I have been using that to try to debug what is causing the disk spinup

Your diagnostics agrees that disk2 has files for that share.

Thanks for the help! Disk2 does indeed have files in that share. I think what I didn't understand is that it must read the disk when anything in that share is accessed or modified, regardless of whether it currently exists on the cache drive or not.

 

In the end, I was able to "fix" it a bit by disbaling file history in windows, and reverting back to using only veeam for backup. I tried the "folder caching" plugin, but the default without user shares didnt fix it. User shares included did fix the spin up problem, but led to much higher CPU usage that more than negated all the power gains from sinning down disks because it could never sleep. So, for now I guess I consider this solved for me.