I seed a lot, so often times my disks don't get a chance to spin down a lot. That by itself is expected - it's a bed I've made and I'm okay with it.

However, I would expect at least my parity drive to stay spun down and it rarely does stay that way for longer than an hour.

 

My docker image as well as all containers are on my the cache only. As far as I can tell, no files are written outside of /cache and/or /mnt/user/appdata.

'find /mnt/ -type f -mmin -10' hasn't really shown anything unexpected when the parity drive spins up.

I've moved all my jobs to run at midnight so there should really not be writes and very few reads. I've used the FileActivity plugin as well and while there were a bunch of open files (reads) from backups running to Backblaze or Immich but no writes outside of the cache.

 

What else can I do here? 

htpc-diagnostics-20250316-1918.zip

1 hour ago, Schaka said:

would expect at least my parity drive to stay spun down and it rarely does stay that way for longer than an hour

A write to ANY data drive will spin up the parity drive as parity is mai trained in real time.

Download the Open Files plugin, start it and it will monitor which files get accessed. From there you’ll have to figure out what might be accessing the files listed.

11 hours ago, itimpi said:

A write to ANY data drive will spin up the parity drive as parity is mai trained in real time.

But not writes to cache, right?

So then why does my drive spin up when the only writes I can identify are to my cache?
None of my drives have been written to according to the command I used above (i.e. file mod date).

FileActivity shows nothing but MOD/ATTR for files on my cache. My cache drive will spin up, I can instantly spin it down again and it will continue to stay spun down for at LEAST an hour in most cases. 

 

5 hours ago, MowMdown said:

Download the Open Files plugin, start it and it will monitor which files get accessed. From there you’ll have to figure out what might be accessing the files listed.

I don't see how that's going to help. I already used FileActivity and it only shows open files. My problem is I need to know what is written to my data drives (and when) so I can identify why my parity drive refuses to stay spun down until the mover is triggered. I installed it just to have a look and it's way too many files - as expected.

Sorry, I meant the FileActivity plugin, which you already are using.

 

Writes to your cache drive will not cause your parity drive to spin up, only writes to any of the array disks. You can also change the view on the dashboard to see which drive(s) have writes being performed on them by clicking the icon on the far right side.

 

Start by stopping all dockers, spin down all drives in the array, see if any disks spin up.

 

If so you have a device on your network reading/writing to the array. Start by finding out which device is accessing your NAS. Otherwise your might have a docker that could be logging to the array.

 

The file activity plugin will tell you which files is being updated. It would be quite easy to figure out what is updating a specific file.

 

Check each disk individually to make sure your cache only shares do not have data on the array disks.

 

You dont have any VMs do you?

 

 

 

Edited March 17, 20251 yr by MowMdown

19 minutes ago, MowMdown said:

Sorry, I meant the FileActivity plugin, which you already are using.

 

Writes to your cache drive will not cause your parity drive to spin up, only writes to any of the array disks. You can also change the view on the dashboard to see which drive(s) have writes being performed on them by clicking the icon on the far right side.

 

Start by stopping all dockers, spin down all drives in the array, see if any disks spin up.

 

If so you have a device on your network reading/writing to the array. Start by finding out which device is accessing your NAS. Otherwise your might have a docker that could be logging to the array.

 

The file activity plugin will tell you which files is being updated. It would be quite easy to figure out what is updating a specific file.

 

Check each disk individually to make sure your cache only shares do not have data on the array disks.

 

You dont have any VMs do you?

 

 

 

 

I'll have to try and catch the exact moment that something writes to a disk. So far I've had no success with that.
I have no VMs and have disabled SMB writes altogether for the time being.

 

I've gone through all my containers to confirm they're on the cache drive (appdata) and none of them should be writing directly to the array, let alone by opening existing files and changing their content. The FileActivity plugin seems to have confirmed that, at least from what I've seen in several hours of monitoring.

I may change some of my mounts to readonly to further narrow down the problem. I've looked my containers' log files and they all seem to be on the cache. The same goes for system log. I did find an old script that was running once every 6 hours that would turn on the cache for my old Adaptec HBA (which I don't have anymore). Since this has been disabled and doesn't run frequently enough to be the culprit, I don't think it's going to entirely fix my problem either.

I'll try to monitor some more and see where that gets me. 

I also forgot to tell you to hit the "Clear Stats" button at the bottom of the MAIN tab, this will zero out the reads/write numbers so you can see easier identify which disks have writes increasing from 0.

6 hours ago, MowMdown said:

I also forgot to tell you to hit the "Clear Stats" button at the bottom of the MAIN tab, this will zero out the reads/write numbers so you can see easier identify which disks have writes increasing from 0.

This helped put me on the right path. Turns out I had been using the extended arr scripts in one container and thought it had been cleaned up, but evidently it was still running.

That in conjunction with the script activating drive cache seems to have been what caused spinups by the looks of it.

 

Parity has now been spun down for 5 hours.