disks are not spinnig down (SOLVED)


Recommended Posts

hi there,

 

some of my disks will not spinning down.. actually they just come up a couple of seconds after pressing the spin down button.

> Parity Disk

> Disk 3

 

Folders on this disk as listed as shown on the screenshot:

Downloads (temp folder for jdownoader docker - not running),

Filme, Musik, Serien (Plex share),

System (Cache prefer)

nextcloud (Cache yes)

 

Things I tried so far:

- Changing Plex to scan new media just once a day

- Nextcloud is stored on this disk, so I changed Loglevel to 2 as know bug at the moment..

- installed the File Activity plugin (just found some activity on cache, not on disk3)

 

 

Running dockers: MariaDB, Nextcloud, binhex-plexpass

Appdata is set to "cache only"

 

On the File Activity log there is no activity between 12:30 and 16:27 - but the disk is still spinup on the gui.

 

Does anybody have a clue why?

Regards so far Tobi.

Bildschirmfoto 2019-06-21 um 16.27.44.png

Bildschirmfoto 2019-06-21 um 16.31.39.png

Bildschirmfoto 2019-06-21 um 16.34.21.png

Edited by Toobie
Link to comment
Just now, Toobie said:

But why?
Nextcloud is set to cache, so it will write first on the ssd.

Sent from my MI 6 using Tapatalk
 

Cache: Yes means NEW files are written to cache, and moved to the array on the mover schedule. Once they are on the array, they will stay there, and if nextcloud opens them for reading, the disk will spin up. If you want all of nextcloud to stay on the cache, you need to set it to cache prefer, and make sure you have enough free space on the cache drive for your nextcloud files.

Link to comment

So, I did a update to 6.7.1 and checked the log after reboot.

No activity in the file log.

 

Nextcloud Pfad: /mnt/user/appdata/nextcloud

--

Appdata is set to Cache Only

Nextcloud is set to Cache Yes

 

But as there is no activity in this, could this any other issue?

Link to comment
4 minutes ago, Toobie said:

So, I did a update to 6.7.1 and checked the log after reboot.

No activity in the file log.

 

Nextcloud Pfad: /mnt/user/appdata/nextcloud

--

Appdata is set to Cache Only

Nextcloud is set to Cache Yes

 

But as there is no activity in this, could this any other issue?

As stated before, recommend you change NextCloud to Cache prefered and see if the problem persists.

Link to comment

Iam unsure if this is really Nextcloud related.

 

Found this in the system log, can somebody explain this please?

 

Jun 24 10:55:05 T30 emhttpd: Spinning down all drives...
Jun 24 10:55:05 T30 kernel: mdcmd (53): spindown 0
Jun 24 10:55:05 T30 kernel: mdcmd (54): spindown 1
Jun 24 10:55:05 T30 kernel: mdcmd (55): spindown 2
Jun 24 10:55:05 T30 kernel: mdcmd (56): spindown 3
Jun 24 10:55:06 T30 kernel: mdcmd (57): spindown 4
Jun 24 10:55:06 T30 emhttpd: shcmd (109): /usr/sbin/hdparm -y /dev/sdf
Jun 24 10:55:06 T30 root: 
Jun 24 10:55:06 T30 root: /dev/sdf:
Jun 24 10:55:06 T30 root:  issuing standby command

 

Also I stopped MongoDB & Nextcloud, hammerd the spin down button of the disks 0&3 (parity&disk3) but they came back immediately.

Edited by Toobie
Link to comment
1 minute ago, Toobie said:

Iam unsure if this is really Nextcloud related.

 

Found this in the system log, can somebody explain this please?

 


Jun 24 10:55:05 T30 emhttpd: Spinning down all drives...
Jun 24 10:55:05 T30 kernel: mdcmd (53): spindown 0
Jun 24 10:55:05 T30 kernel: mdcmd (54): spindown 1
Jun 24 10:55:05 T30 kernel: mdcmd (55): spindown 2
Jun 24 10:55:05 T30 kernel: mdcmd (56): spindown 3
Jun 24 10:55:06 T30 kernel: mdcmd (57): spindown 4
Jun 24 10:55:06 T30 emhttpd: shcmd (109): /usr/sbin/hdparm -y /dev/sdf
Jun 24 10:55:06 T30 root: 
Jun 24 10:55:06 T30 root: /dev/sdf:
Jun 24 10:55:06 T30 root:  issuing standby command

 

That is Unraid attempting to spin down the drives.      However any attempt to access a file on them them will result in them promptly spinning up again.    This is handled at a low level in the Linux kernel and there are no corresponding spin up entries in the syslog when that happens.

Link to comment
24 minutes ago, Toobie said:

Ok, one more suggestion.

/mnt/disk3/system/docker/docker.img

 

This might be the reason for spinning up disk3 and the parity device.

Is it possible to move this image to the cache?

Yes - that would cause disk3 and parity to spin up if you were running any docker images.

 

Start by making sure the 'system' share is set to Use Cache=Prefer.  Then to get the docker.img fille  on the cache there are two choices:

  • Make sure the Docker service is stopped and run mover to get the file moved to the cache.   You can restart the docker service when this completes
  • Make sure the Docker service is stopped; delete the current docker image; restart the Docker service to get a new docker.img file created on the cache;  Use the Previous Apps option on the Apps tab to reinstall your docker containers with their current settings intact.

Which one you use is up to you.  There is case for trying the second one on the basis it is the one you would use if your docker.img file ever got corrupted so it is nice to have tried the process out in advance.

  • Like 1
Link to comment
1 hour ago, itimpi said:

Yes - that would cause disk3 and parity to spin up if you were running any docker images.

 

Start by making sure the 'system' share is set to Use Cache=Prefer.  Then to get the docker.img fille  on the cache there are two choices:

  • Make sure the Docker service is stopped and run mover to get the file moved to the cache.   You can restart the docker service when this completes
  • Make sure the Docker service is stopped; delete the current docker image; restart the Docker service to get a new docker.img file created on the cache;  Use the Previous Apps option on the Apps tab to reinstall your docker containers with their current settings intact.

Which one you use is up to you.  There is case for trying the second one on the basis it is the one you would use if your docker.img file ever got corrupted so it is nice to have tried the process out in advance.

 

Awesome @itimpi!

I really appreciate your detailed answer!

I chose the first Choice as it seemed easier for me and it worked.

 

Nextcloud, MariaDB & binhex-Plexpass are running as usual and all drives are now on standby, except the cache.

The point that Mover will not move the system files (docker images) while they are running wasn't clear to me.

 

As a summary for other ppl: Set the desired share (in my point system, appdata, domains) to Cache=Prefer and be sure that the docker service is not running while Mover is moving your files.

 

It seems that my Challenge is solved now, I will give an update tomorrow.

Edited by Toobie
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.