[SOLVED] Drive not spinning down

[afmed]

Hi, 

 

I have recently spent a bunch of time moving files around on my array, in a hopes to keep the active data on 1 drive, expecting the others to mostly spin down.

 

This has worked quite well, the number of spin ups seems to have reduced, but I am noticing that 1 drive tends to stay spun up for no external reason.

It contains uncompressed backups of old linux VMs and various other backups that I need to, at some point, organise/delete.  

 

The shares on that drive are not accessed by anything external to the server. I can't see anything on my LAN accessing the shares

 

I sometimes notice its drive light flashing, at this point running "lsof | grep disk15" shows shfs seemingly scan the drive.

I do have 'Dynamix Cache Directories' installed, but have disabled it and/or excluded the shares on disk15. it has not made a difference.

 

I suppose my question is, is there a process in unraid that scans the drives periodically? 

If so, can I make it stop

 

Thanks for any help and thanks for Unraid.

 

Cheers

Aftab

[trurl]

Some plugins that might help:

 

Dynamix Active Streams:

https://forums.unraid.net/topic/34889-dynamix-v6-plugins/

 

File Activity:

https://forums.unraid.net/topic/54808-file-activity-plugin-how-can-i-figure-out-what-keeps-spinning-up-my-disks/

 

Open Files:

https://forums.unraid.net/topic/41196-open-files-plugin-can-help-with-troubleshooting-why-server-wont-shut-down/

 

 

Also, go to Tools - Diagnostics and attach the complete diagnostics zip file to your next post so we can take a closer look.

[afmed]

Hi, 

 

Thanks for the response.

 

'Open Files' showed me that smbd was accessing my backup share.  Windows added some of the sub folders of that share to my quick links.  I've removed them now.

The 'Active Streams' username tab showed me that my nVidia shield, while in standby was a client. (I have a rootshare configured)

 

To this end, I've changed the permissions on the folders within the backup share to root:root 700.  Lets see if that stops the scanning.

 

regardless, i have attached the logs.

Cheers

Aftab

 

littlevault-diagnostics-20190511-1255.zip

[trurl]

Your system share is on disk1. And that share is where your docker image is configured. So, your dockers are going to keep parity and disk1 spinning, and they won't perform as well due to the slower parity writes.

 

The default for the system share is cache-prefer, but for some reason you have it set to cache-yes.

 

Cache-yes means write new files to cache then move them to the array.

 

Cache-prefer means try to keep files on cache. Cache-prefer means write new files to cache, and if it gets full, overflow to the array, but move them back to cache when there is room.

 

But, mover can't move any open files, so even if you change system share to cache-prefer as it should be, the docker image can't be moved while the docker service is enabled.

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.

[trurl]

Also, on that same page where you are recreating your docker image, turn on log rotation.

[trurl]

Post new diagnostics after you have made those fixes.

[trurl]

Forgot about your VMs. Your libvirt image is also in system share. After fixing your dockers:

1. Disable VM service.
2. Run mover to get the rest of the system share moved to cache where it belongs.
3. Enable VM service.

You can check which disks are used by each user share by going to User Shares and clicking Compute... or use the Compute All button. It will take some time to produce the results.

[afmed]

thanks, I just noticed that myself and already moved it.

then the docker page suggested an issue with the image, so I deleted it any how.

 

I've also unmounted and moved the ISOs to disk 1, it looked like browsing the VMs page scanned the iso share.

 

Cheers

littlevault-diagnostics-20190511-1435.zip

[trurl]

Looks good but you missed this:

24 minutes ago, trurl said:

Also, on that same page where you are recreating your docker image, turn on log rotation.

 

[afmed]

Odd, I look at the page, it says its on...

 

[afmed]

generated again, maybe i got the order wrong

 

littlevault-diagnostics-20190511-1452.zip

[trurl]

Yes that worked.

 

[afmed]

Hi,

 

I moved the contents of disk 15 to disk 8.  It is now empty.

 

If I spin up all drives, all the others spin down, except for 1 which has active data and 15 which has no reason to stay active.

 

Any ideas?

New diags attached 

 

Cheers

Aftab

littlevault-diagnostics-20190514-0753.zip

Edited May 14, 2019 by afmed

[trurl]

Click on disk15 and make sure it is set to spin down.

[afmed]

Hi trurl, 

 

So I feel like a right idiot.  Somehow it was set to never.  Changed it to Default and it immediately spun down.

 

Thank you for all your help.

 

Cheers

Aftab

[trurl]

1 hour ago, afmed said:

Somehow it was set to never.  Changed it to Default and it immediately spun down.

I'm not sure how that happens since that is not the default. I had it happen to me once. When you run a SMART test on a disk it sets it to not spin down but it is supposed to set it back after the test. Maybe sometimes it doesn't.

[afmed]

That could explain it.  As I first started to use the array, 15 was the first disk I filled up and I remember it having some errors which eventually went away.

 

I would have run tests, and more than likely I didn't wait for the short to finish before starting a long.  The second test would have seen the previous state as never and kept it set to never at the end.

 

Something to remember.

 

Cheers again