Disks Won't Spin Down


Dulanic

23 posts in this topic Last Reply

Recommended Posts

Hello,

 

OK I am going crazy over this. None of my disks will stay spun down. Even my empty drives will spin up immediately after I spin one down. The longest I can get ANY drive to spin down is maybe 3-4 seconds. Here is what I have checked so far:

 

1. All appdata is on a cache drive.

2. All actively used data is on cache data. The shares that are not on cache are one's I might access a few times a day.

3. Checked open files plugin and all open process/files are on the cache drive only.

4. Spinup groups is disabled.

 

Any other ways to find out what is the cause?

Link to post

Could be basically anything.  An app scanning your files.  Windows scanning the directories.  Limited RAM and cachedirs causing the disks to spin back up.  Appdata for your docker apps not set to be a cache only share (or cache prefer) causing unRaid to actively think about where to put the data

 

Diagnostics is the first tool to help

 

Link to post

So I think I completely misunderstood the cache system and had cache off on most of my shares. Hopefully that will fix my problem.

 

I suspect that was indeed the issue -- i.e. any reference to any of your non-cached shares would cause at least one drive to spin up.  I suspect with all of your shares cached you'll see far fewer drives spin-up from writes.  [they will still, of course, spin up if you're reading data that's on one of the data drives]

 

Link to post

Yeah so even /w cache on I am seeing spin up within seconds of spinning down. It seems something is writing, is there any possible way to track what is writing? I see small party write increases but I have no way to know what is doing the writes so far. The longest I have ever seen a full spin down is 30 seconds.

 

From my knowledge what I have running shouldn't be actively writing... but something is, at least small amounts.

Link to post

Are you running some Dockers or VM's that might be writing to the array?    If you're not sure which one(s), just disable all of them, and then enable them one-at-a-time to see when your drives start being accessed.

 

Clearly if there are writes to the parity drive, there are also writes to at least one of your data drives -- so these are what are causing the drives to spin up.    The trick now is simply to isolate WHAT is doing the writing  :)

Link to post
  • 3 years later...
  • 4 weeks later...
  • 1 month later...

Hi everyone, I have recently had the same issue of disks not spinning down.  I seem to have managed to solve this (I believe) but I wanted to document what I believe the causes were.  Whenever disks were not spinning down I could see a consistent ~3.4KB/s read from the disks in question.  I could not see what was reading these disks as it was not listed in "Open Files" or "File Activity" tools/plugins that I have installed.

So in my case what it looks like the cause was that I had shares which I had reconfigured to exist only on one disk, or to live purely on the cache drive (cache "only"), but the file allocation system of unRAID appeared to not be fully respecting this.   What it looks like is that even if there is a blank directory on a disk that previously contained components of a share, then any disk writes to that share still keep probing that disk and keeping the disk spun up.

The solution in my case was to do the following:

  1. Shut down all VMs and Docker containers
  2. Edit all shares that need to only be on the cache to "Prefer" for the cache setting
  3. Run the Mover
  4. Edit the same shares again to use "Only" for the cache setting
  5. Review all shares that should only be one some (or one) of the disks and make a list of these
  6. Download and install unBALANCE and run it
  7. Use unBALANCE to "Gather" any of those shares that should only be on specific disks, and place those shares only on the disk targets that I wanted them on
  8. Stop unBALANCE
  9. Spin down all the disks I know should be spun down during idle times
  10. Start all the VMs and Docker Containers I need running

After that, I confirmed that my disks stayed spun down.  For the past 30 minutes, I've not seen any of these disks spin up so it looks stable (so far).  Note that all my VMs and containers run off the SSD cache which is a 1TB mirror.

You might ask "why care about this"?  Well since my server is running 24/7 the difference in power consumption between the disks being spun up and not being spun up is about 35 watts.  This seems "like nothing" but power is not cheap here in Australia.  During peak times we pay 38c cents per kw/h.   Every little bit of my base load ends up going towards a yearly power bill of $1,500 and that's after all the rebates from my 5kw/h solar array (which pays me 12c kw/h for exported power).

My entire server rack - at idle now - pulls 151 watts.  Two weeks ago that idle was 240 watts, which is a near 90 watt saving.  I've gained about 40-45 watts of this saving from unRAID tuning.  The rest came from replacing outdated Unifi UAP-AC access points with newer UAP-AC-LR access points that pull much less power.

Edited by Kaldek
Link to post
7 hours ago, Kaldek said:

 Every little bit of my base load ends up going towards a yearly power bill of $1,500 and that's after all the rebates from my 5kw/h solar array (which pays me 12c kw/h for exported power).

Wow, that's low. I know it's a matter of perspective, but my annual power spend is typically around $4,800 USD, and I'm in the southeastern US.

Link to post
  • 2 months later...

Hi everyone,

 

I have trouble with disk spinning down too, but only with one of them.
The others go and stay spin down correctly.

In the dashboard tab, the disk status is'standby', but it spins in reality.

If I run a hdparm -C command, its state is active.

 

So what command uses unraid/dashboard to say the disk is active/standby ?

 





 

Link to post
2 minutes ago, mika91 said:

Hi everyone,

 

I have trouble with disk spinning down too, but only with one of them.
The others go and stay spin down correctly.

In the dashboard tab, the disk status is'standby', but it spins in reality.

If I run a hdparm -C command, its state is active.

 

So what command uses unraid/dashboard to say the disk is active/standby ?

 





 

Which disk is it ?

Have you check the properties for tbat disk, to see if tbe spin down function is set

Link to post

It's an empty data disk.
If I press manually the spindown/up buttons in the GUI, it responds accordingly. (and hdparm -C command reflects it)

But after a certain time, the disk spin up (hdparm confirm it) but stay 'standby' in the dashboard.

No file activity. (excpect on /mnt/cache)

 

Edited by mika91
Link to post

Done some more tests tonight.
All docker containers stopped.

 

Manually spin-down the 'faulty' disk -> hdparm staus is 'standby'

After 15 minutes exactly, the disk spin up (butunraid continue to mark it as spun-down)

I checked 'file activity', it's clear: nothing on any disk.

Could it be a firmware issue of the disk (seagate barracuda 7200 ST3000DM001), or a tweak needed ?

However, it sounds unraid rely on the command it sends to the disks to determine their status (no 'real-time' status)

Edited by mika91
Link to post
  • 6 months later...

I think I read someone somewhere saying that the SMART test was keeping the drives awake by resetting the spin down timer.  If you use 1 hour spin down delay try changing the Tunable (poll_attributes) setting to something above the hour (or above the spin down delay you have set).  I have mine set to 1 hour spin down and 7200 for the tunable setting.

Link to post

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.