HDD Spindown doesn't work

[Stoker]

Hi everyone!

The Spindown of my HDDs doesn't work. When I click on spindown manually, the HDDs will spin down for a few seconds and then they spin up again. The Only drive where the spindown works is the parity drive.

 

I run a few Docker containers and I think the appdata is stored not only on the cache drive, but also on the share. Could that be the Problem?

 

I'm new to Unraid and ran OMV before, so I'm not that familiar with the way Unraid works exactly.

 

Thanks for your Help

 

System:

DELL T20 with XEON and 8GB ECC

3x 8TB HDD for Share

1x 8TB HDD for Parity

1x 500GB SSD for Cache

Containers: Nextcloud, PLEX, NGINX proxie manager

tower-diagnostics-20211010-2051.zip

[Squid]

appdata only exists on the cache drive.  But, IIRC correctly, nextcloud is notorious for this (continually reading from the paths you add to it), which will keep the drives spun up

[Stoker]

Thanks for your answer!
I only use one drive for my nextcloud data. But all 3 drives won't spin down, so I think there must be another problem.

[trurl]

2 hours ago, Squid said:

appdata only exists on the cache drive

But your system share has files on disk2

[Stoker]

6 hours ago, trurl said:

But your system share has files on disk2

You are correct. But what exactly does this mean and how can I solve my problem.

 

The only Disk that spins down is Disk 1. All other drives doesn't.

[peteq]

Hi Stoker -- I was having a similar problem and this advice solved it for me (read the whole thread):

 

Quote

 

1. Set system share to cache-prefer.
2. Disable docker service and delete the docker image.
3. Enable docker image to get it recreated on cache where it belongs.
4. Reinstall your dockers using the Previous Apps feature on the Apps page. The Previous Apps feature knows how you had them before and will use those settings.

 

 

 

Edited October 11, 2021 by peteq

[Stoker]

7 hours ago, peteq said:

Hi Stoker -- I was having a similar problem and this advice solved it for me (read the whole thread):

 

 

My settings for the system Share where "Use cache pool: Prefer". So I stoped and deleted the Docker Container and reistalled them with the "previous Apps" function.

But that didn't solve my Problem. Did I do something wrong?

 

 

 

tower-diagnostics-20211012-0833.zip

[itimpi]

17 minutes ago, Stoker said:

 

My settings for the system Share where "Use cache pool: Prefer". So I stoped and deleted the Docker Container and reistalled them with the "previous Apps" function.

But that didn't solve my Problem. Did I do something wrong?

 

 

 

tower-diagnostics-20211012-0833.zip 87.49 kB · 0 downloads

You need to stop the Docker and VM services (not just a container) and then run mover from the Main tab to get the share moved to the cache.   These services hold files open in the system share while they are active stopping mover from acting on them.  When mover completes you can then re-enable these services.

[Stoker]

1 hour ago, itimpi said:

You need to stop the Docker and VM services (not just a container) and then run mover from the Main tab to get the share moved to the cache.

 

Ah! OK, now I got it.

Now Disk 1 and Disk 2 stay in Spin Down. But Disk 3 and my Parity Disk don't.

 

@Squid mentioned Nextcloud would be a Problem for spinning down the disk. So it makes sense that Disk 3 doesn`t spindown. Is there any way to solve that or do I have to live with this when I want to use Nextcloud? Is likewise responsible for not spinning down the parity disk?

[itimpi]

1 hour ago, Stoker said:

mentioned Nextcloud would be a Problem for spinning down the disk. So it makes sense that Disk 3 doesn`t spindown. Is there any way to solve that or do I have to live with this when I want to use Nextcloud? Is likewise responsible for not spinning down the parity disk?

Since Nextcloud share is on disk3 then it is almost certainly responsible for keeping that disk spinning.   

Since any writes to any drive will result in the parity drive spinning then that is probably also the culprit for that behaviour if Nextcloud is ever writing to that share.

[Domotics]

  my nextcloud issue is solved by adding these two lines to the config.php

'logfile' => '/ext_logs/nextcloud_logs/nextcloud.log',
'logfile_audit' => '/ext_logs/nextcloud_logs/audit.log',

 

More details on it here and here

[JonathanM]

5 hours ago, Domotics said:

  my nextcloud issue is solved by adding these two lines to the config.php

'logfile' => '/ext_logs/nextcloud_logs/nextcloud.log',
'logfile_audit' => '/ext_logs/nextcloud_logs/audit.log',

 

More details on it here and here

Unless you also implement something to clean them out this will likely balloon your docker image file.

[ChatNoir]

And/or adjust the docker template so they are written on a pool ?

[Domotics]

11 hours ago, JonathanM said:

Unless you also implement something to clean them out this will likely balloon your docker image file.

ext_logs is share with cache (only) and this share is mounted as an external path on the nextcloud container. so this is not on the docker itself. 

[Domotics]

6 minutes ago, Domotics said:

ext_logs is share with cache (only) and this share is mounted as an external path on the nextcloud container. so this is not on the docker itself. 

 

this is how is it setup on nextcloud

 

 

and this is the share settings.

 

[JonathanM]

4 minutes ago, Domotics said:

ext_logs is share with cache (only) and this share is mounted as an external path on the nextcloud container. so this is not on the docker itself. 

How is someone trying to follow your advice supposed to know that?

 

Most folks trying to solve this issue would assume what you posted was all you did, since you didn't explain all the needed parts.

[JonathanM]

17 hours ago, Domotics said:

my nextcloud issue is solved by adding these two lines to the config.php

Perhaps you should add the rest of the instructions to this post.

[Domotics]

10 minutes ago, JonathanM said:

Perhaps you should add the rest of the instructions to this post.

That is a fair point. posted couple of screenshots above. more more clarity i will mentioned the details again below.

 

 

1. setup a new share for storing log files (preferably set to cache only so it will not harm the spinning disks) - example screenshot below

 

2. Edit nextcloud container settings and add an additional path and point it to the share created in the previous step.

 

 

3. edit the config.php (normally located on /mnt/user/appdata/nextcloud/www/nextcloud/config/config.php) and add the below lines somewhere in between the other configs there.

'logfile' => '/ext_logs/nextcloud_logs/nextcloud.log',
'logfile_audit' => '/ext_logs/nextcloud_logs/audit.log',

 

4. restart the nextcloud container.

 

5. verify the disk with nextcloud data is spinning down after the timeout you set.


Hope this helps.

Edited June 9, 2022 by Domotics

[TekDRu]

Hey @Domotics,  just wanted to come back and say thanks for this.  It solved my problem after an update to nextcloud 25.  I don't know what happened but it seems like my config file got overwritten after the update and the log file was saved to the array again.  I think this fix should work for future updates.

 

Thanks!