Hi all,

 

I've got a minor issue which I have seen referenced in a couple of threads here and on reddit but none seem to have concluded with a fix or anything that seems to apply to my situation. 

I have 5 disks in my array, and all are set to spin down after 15 minutes. While I know some consider spinning the drives down and up again when needed to cause wear, the power saving is worth it IMO, and a lot of what I access most frequently is on the cache anyway.

2 of these 5 drives (sdd - the parity drive & sde - the most recently installed drive, which replaced a failed drive) stay spinning all the time, while the rest spin down. If I force them to spin down, they spin up again after a couple of minutes. I had a quick look at the log, but it just says 'read SMART' for both drives, with no further details. The SMART checks all look fine, and there are no scheduled SMART checks. I have read somewhere that a SMART check is automatically initiated any time the drive spins up, so I think this may be a symptom, not the cause.

I have also read that if a drive spins up because of a request from a docker container, this is not shown in the log. I stopped all my dockers (deluge vpn, krusader, lancache, and plex), spun the drives down, and the 2 drives spin back up again immediately, even quicker than when the dockers were running. I should also say that the lancache is set up on a seperate drive from the array. 

 

I'm afraid I'm not well versed in Linux or unRAID, and a friend helped me build and set up this system, and has helped me when I have (thankfully very rarely) had an issue, but he is stumped by this as well. So I apologise if I'm missing something very obvious, or something I should have tried first. I've attached my logs, which hopefully allow some insight to the issue. 

 

Thanks

Charlie

 

tower-diagnostics-20221222-1549.zip

Your appdata, domains, system shares have files on the array. Ideally these should all be on fast pool (cache) with no files on the array. Docker/VM performance will be impacted by slower array if these files are on the array. More importantly for your question, if these files are on the array, array disks can't spin down because these files are always open. With no docker running, appdata won't be open, but files in system share are always open whenever Docker and/or VM Manager is enabled in Settings even if no dockers/VMs are running.

 

If you have large vdisks you might have to keep domains on the array. If not, set domains share to cache:prefer.

 

Nothing can move open files. Disable Docker and VM Manager in Settings, run mover to get these moved to cache.

 

Mover won't replace files so if any already exist on cache they won't be moved. You will have to decide which to keep. Installing Dynamix File Manager plugin will help with this.

Hi,

 

thanks for your reply, I really appreciate it. 

I have no vdisks or virtual machines, my VM manager is always off.  Appdata was already set to prefer:cache.

I have tried what you suggested, first shutting down docker and the invoking 'Move', 

I then started the docker again, and the same drives spin back up.

I the shut down the docker again, and used Dynamix File manager to move the appdata folders present on the array disk in question over to the cache, and started up the docker again. Still, the drives spin back up. 

I've attached an updated log, do you have any other suggestions?

 

Thanks again,

Charlie 

tower-syslog-20230101-2155.zip

3 hours ago, Charlie W said:

attached an updated log

You should attach diagnostics instead, it includes syslog and many other things that help make sense of your setup. I often don't even look at syslog until I have looked at other things in diagnostics for context.

Hi again,

 

when I went to download the diagnostics this morning it appears that all the drives are now spinning down correctly, despite not doing so at all yesterday. So hopefully the issue is solved!

I've attached my diagnostics anyway, and I'll keep checking the array this week. If it's still behaving itself by Friday I'll mark you initial reply as the solution.

 

Thank you very much for taking the time to help,

Charlie 

tower-diagnostics-20230102-0947.zip