Cannot spin drives down

[Ellis34771]

I've noticed recently that all of my drives are *always* spun up.  

I can't seem to find a setting that prevents them from shutting down.  

 

Making matters worse, when I manually try and spin them down, they stay spun up.  No obvious errors in the log.  (So I literally cannot spin them down by any means).

 

Any thoughts?  Any more information or logs that I need to upload?

 

[JorgeB]

Please post the diagnostics.

[Ellis34771]

Attached.

elsa-diagnostics-20230323-1246.zip

[JorgeB]

Nothing obvious, to confirm there's nothing external accessing the disks start the array in maintenance mode and see if they stay down.

[Ellis34771]

Just now, JorgeB said:

Nothing obvious, to confirm there's nothing external accessing the disks start the array in maintenance mode and see if they stay down.

 

I'll give that a try and post the results. 

I'm not sure when this started, but it had to be fairly recently.  (I'd have noticed at some point).  Not the end of the world, but my drives have plenty of hours on them, would prefer to make them last a bit longer, and save a bit of power.  (It's one of the main points of Unraid, right?)

 

Just odd that I can't even manually spin any of them down.  

 

... more soon.

[Ellis34771]

I did find this in the log, whenever I do a spin down:

What is the read SMART after each spin down attempt?  

 

Mar 23 13:37:28 Elsa  emhttpd: spinning down /dev/sdf

Mar 23 13:37:32 Elsa  emhttpd: read SMART /dev/sdf

Mar 23 13:37:36 Elsa  emhttpd: spinning down /dev/sdj

Mar 23 13:37:39 Elsa  emhttpd: read SMART /dev/sdj

Mar 23 13:37:41 Elsa  emhttpd: spinning down /dev/sdi

Mar 23 13:37:41 Elsa  emhttpd: spinning down /dev/sdh

Mar 23 13:37:42 Elsa  emhttpd: read SMART /dev/sdh

Mar 23 13:37:44 Elsa  emhttpd: read SMART /dev/sdi

Mar 23 13:37:49 Elsa  emhttpd: spinning down /dev/sdg

Mar 23 13:37:50 Elsa  emhttpd: read SMART /dev/sdg

Mar 23 13:37:53 Elsa  emhttpd: spinning down /dev/sdf

Mar 23 13:37:54 Elsa  emhttpd: read SMART /dev/sdf

Mar 23 13:37:56 Elsa  emhttpd: spinning down /dev/sdd

Mar 23 13:37:59 Elsa  emhttpd: spinning down /dev/sdc

Mar 23 13:38:01 Elsa  emhttpd: read SMART /dev/sdd

Mar 23 13:38:01 Elsa  emhttpd: read SMART /dev/sdc

Mar 23 13:38:22 Elsa  emhttpd: spinning down /dev/sdf

Mar 23 13:38:26 Elsa  emhttpd: read SMART /dev/sdf

Mar 23 13:38:31 Elsa  emhttpd: spinning down /dev/sdh

Mar 23 13:38:32 Elsa  emhttpd: read SMART /dev/sdh

Mar 23 13:38:39 Elsa  emhttpd: spinning down /dev/sdi

Mar 23 13:38:40 Elsa  emhttpd: read SMART /dev/sdi

[JorgeB]

Read SMART means that Unraid detected that drive spun up and so is reading the SMART data.

[Ellis34771]

Thanks.  Appreciate that.  So all it's doing is confirming the immediate spin up.  (sigh).  Maintenance mode it is.

 

[Ellis34771]

Well, I tried this in maintenance mode, and the drives all still spun up.  Bizarre.  

 

I'm at a loss on how to troubleshoot this beyond here.  

 

[JorgeB]

Actually after my last post I tried that and for some reason drives don't stay spun down in maintenance mode, instead boot in safe mode, disable VM and docker services and try again after that.

[Ellis34771]

On 3/24/2023 at 4:31 AM, JorgeB said:

Actually after my last post I tried that and for some reason drives don't stay spun down in maintenance mode, instead boot in safe mode, disable VM and docker services and try again after that.

OK, I shut down all VMs (Normally not running anyway).  I shut down ALL dockers.  Same issue.  

What else can I shut down?  

 

[Ellis34771]

Oh, even more interesting.  If I stop the docker SERVICE, I can spin the drives down.   But if I start the service (even with zero (0) dockers running, ALL the drives spin up again.  

 

This is beyond weird.

 

[SimonF]

8 hours ago, Ellis34771 said:

Oh, even more interesting.  If I stop the docker SERVICE, I can spin the drives down.   But if I start the service (even with zero (0) dockers running, ALL the drives spin up again.  

 

This is beyond weird.

 

Where is the location of your dockers, can you look at the system share to see where dockers images are located? Do you have turbo writes enabled?

Edited March 29, 2023 by SimonF

[itimpi]

I notice that the ‘appdata’ share has files all over the array drives despite it being set to Use Cache=Only.   With that setting mover will ignore the files on the array - you need Prefer (with Docker service disabled when running mover) to get them onto the cache.   If any still do not move they may be duplicates of files already on the cache as mover will also not move duplicates - they need deleting manually.   Whether that is a cause of your issue I have no idea but it makes sense to tidy that up anyway.

[Ellis34771]

8 hours ago, SimonF said:

Where is the location of your dockers, can you look at the system share to see where dockers images are located? Do you have turbo writes enabled?

 

The docker image is located at /mnt/disk1/docker.img

I can probably move it to the cache drive.  But that's still just a single disk.

Turbo writes are in fact enabled.

 

[Ellis34771]

7 hours ago, itimpi said:

I notice that the ‘appdata’ share has files all over the array drives despite it being set to Use Cache=Only.   With that setting mover will ignore the files on the array - you need Prefer (with Docker service disabled when running mover) to get them onto the cache.   If any still do not move they may be duplicates of files already on the cache as mover will also not move duplicates - they need deleting manually.   Whether that is a cause of your issue I have no idea but it makes sense to tidy that up anyway.

Yeah, that's been bugging me for a while.  I'm not sure how they got that way, and mover doesn't touch them.  That's on my list of things to look at.  It appears that *most* of the appdata stuff is old and long since deprecated, but I want to take a methodical approach to deleting it so I don't accidentally shoot myself in the foot.

 

Good catch though, I appreciate it.

 

I'm going to resolve this.  It's become a quest at this point. 

 

[itimpi]

16 minutes ago, Ellis34771 said:

The docker image is located at /mnt/disk1/docker.img

I can probably move it to the cache drive.  But that's still just a single disk.

Turbo writes are in fact enabled.

With Turbo writes enabled, writing to any drive will spin up all drives.

[Ellis34771]

I think I may have solved this.  

 

I had the spin down time at 2 hours.  My Time Machine backup on my work MBP was hourly.  I've lowered the spin down time to 15 minutes.  It seems OK for the moment.  (I also cleaned up the AppData mess).  Also: Turned turbo-writes off for the moment.  I may turn that back on, but I'm doing this one step at a time.

Currently my doctor is on disk1, and my thinking at the time was then it is backed up on the parity disk.  Wondering if I should move that to the cache disk and Implement a separate backup for that?  (Any thoughts?)

 

Thank you all !!

[JonathanM]

2 hours ago, Ellis34771 said:

it is backed up on the parity disk

Parity is NOT a backup.

[Ellis34771]

49 minutes ago, JonathanM said:

Parity is NOT a backup.

Agreed, and a poor choice of words on my part.  

 

What I mean is that the parity makes it a lot easier to replace if the single drive goes down.  (Rebuild).  I have other backup solutions in place for critical data.  (Including an older QNAP server that mirrors many critical files thru RSYNC).