Re: unRAID Server Release 6.0-beta12-x86_64 SPINDOWN/SPINUP ISSUES


209 posts in this topic Last Reply

Recommended Posts

Could you boot without Dynamix and see what is happening?

 

You can't boot without dynamix.  It is the default webgui in b12.

 

Disk health has been integrated in b12.  That is how the disk health indicators work on the dashboard page.

 

I had this problem with a WD RE-4 enterprise drive that would not spin down.  WD reds will spin down.  I suspect that the way the disk health polling is working on some drives, it spins them up.

 

It will get worked out as LT understands the problem better.

Link to post
  • Replies 208
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

There are some indications above that the issue may be specific to certain drive models, such as a number of WD drives.  It could be useful to see the exact drive models for all drives that won't stay spun down.

Link to post

I noticed this after upgrading as well, but when I was about to report it, the issue went away and I didn't want to bring up something I couldn't reproduce.

 

Last two days, it has come back. Here are my drive models using Weebotech's command experiencing the problem:

 

lrwxrwxrwx 1 root root  9 Dec  2 10:20 ata-WDC_WD20EARX-00PASB0_WD-<SNremoved> -> ../../sdf

lrwxrwxrwx 1 root root  9 Dec  2 10:20 ata-WDC_WD20EARS-00MVWB0_WD-<SNremoved> -> ../../sdc

 

I initially only noticed it on the sdf device (disk 1 for me, sdc is disk 2).

 

Checked lsof and no open files on those drives. I have plex, but it is outside the array on a cache drive (along with all my other dockers). No cache_dirs.

 

Appears to have tried to spin them down about an hour ago:

 

Dec 9 08:59:26 Tower kernel: mdcmd (184): spindown 1

Dec 9 08:59:57 Tower kernel: mdcmd (185): spindown 2

 

Edit: adding in smartctl output:

 

root@Tower:~# smartctl -n standby -A /dev/sdc

smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.17.4-unRAID] (local build)

Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

 

Device is in STANDBY mode, exit(2)

root@Tower:~# smartctl -n standby -A /dev/sdf

smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.17.4-unRAID] (local build)

Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

 

Device is in STANDBY mode, exit(2)

Link to post

Drives seem to be spinning up for me as well for no reason.

 

I didn't see it happen in real time, but based on the attempt to spin down drives 1 and 2 in the unraid log 18 minutes later (I have 15 minutes set), this entry may be around the time they spun up:

 

Dec 11 08:12:07 Tower shfs/user: shfs_rmdir: rmdir:

 

But the show that it tried to remove from sab's incomplete directory wasn't done yet. Sab didn't show it done until 8:14.

 

I am using a cache drive, so even if it was able to remove it, I don't know why 2, let alone 1, of my array drives would spin up.

 

This is all assuming that this is what caused them to come up. I'll see if I can catch it happen by manually downloading something.

Link to post

@limetech - any hope to version 12a or some 12"x"  to fix that issue ? my version now taking everyday more power than usual becuase of this :(

 

Of course!  We aren't going to leave issues like this out there forever.  We just ask that folks be patient as we work to identify the root cause and resolve.  If the issue of power consumption is a big enough concern to anyone, unRAID 5 is still our currently supported stable version, so that's still an option for folks that NEED power issues resolved right away...

Link to post

@limetech - any hope to version 12a or some 12"x"  to fix that issue ? my version now taking everyday more power than usual becuase of this :(

 

Of course!  We aren't going to leave issues like this out there forever.  We just ask that folks be patient as we work to identify the root cause and resolve.  If the issue of power consumption is a big enough concern to anyone, unRAID 5 is still our currently supported stable version, so that's still an option for folks that NEED power issues resolved right away...

 

Appreciate the reply! Let me know if you need anymore information/testing done to help find the cause. Happy to help.

Link to post

@limetech - any hope to version 12a or some 12"x"  to fix that issue ? my version now taking everyday more power than usual becuase of this :(

 

Of course!  We aren't going to leave issues like this out there forever.  We just ask that folks be patient as we work to identify the root cause and resolve.  If the issue of power consumption is a big enough concern to anyone, unRAID 5 is still our currently supported stable version, so that's still an option for folks that NEED power issues resolved right away...

 

Appreciate the reply! Let me know if you need anymore information/testing done to help find the cause. Happy to help.

 

Any testing folks can do to help point us to what may be causing the spinups would be greatly appreciated.

Link to post

My pair of WD30EZRX also wouldn't spin down automatically.  But I found another posting that suggested to set the global spindown time to 30 min instead of the default 15 min.  It seems to have solved the issue

Link to post

My pair of WD30EZRX also wouldn't spin down automatically.  But I found another posting that suggested to set the global spindown time to 30 min instead of the default 15 min.  It seems to have solved the issue

 

Thanks for the tip. I'll try that out, been using 15 minutes myself always.

 

I tried a manual tv show download and still got these messages:

 

Dec 11 14:02:38 Tower shfs/user: shfs_rmdir: rmdir:

 

But drives never spun up. So that theory is dead. Issue has happened daily, so the 30 minute delay change will be apparent, if it is working, tomorrow I would think. I'll of course give it more time.

Link to post

My pair of WD30EZRX also wouldn't spin down automatically.  But I found another posting that suggested to set the global spindown time to 30 min instead of the default 15 min.  It seems to have solved the issue

 

Well, I tried that too and set mine to 1 hour. It worked 2 or 3 times in a row but after rebooting, I was back to the same behavior. So I did it again, and they did spin down. Problem is that it isn't consistent enough to say it is a problem with the spin down timer setting.

 

I'm getting ready to replace a disk, so this will have to wait a few days. I just want to get to the bottom of this cause it bugs me. I'm not really concerned about my disk not spinning down  ;D  I can do it manually.

 

Gary

Link to post

30 minute setting didn't help. Logged into drive 1 and drive 2 spun up again today.

 

I do not know of any applications/dockers that would have needed to touch them outside the unraid mover. Mover runs at 3:40am and I checked at 10:22am and found 2 disks up, again, after not spinning down at 8am as well (which is also far off from how long the move would have ran for, maybe 4 gigs of data at most).

 

Dec 12 09:27:03 Tower emhttp: Spinning down all drives...

Dec 12 09:27:03 Tower kernel: mdcmd (55): spindown 0

Dec 12 09:27:04 Tower kernel: mdcmd (56): spindown 1

Dec 12 09:27:04 Tower kernel: mdcmd (57): spindown 2

Dec 12 09:27:05 Tower kernel: mdcmd (58): spindown 3

Dec 12 09:27:05 Tower kernel: mdcmd (59): spindown 4

Dec 12 09:27:06 Tower emhttp: shcmd (4271): /usr/sbin/hdparm -y /dev/sde &> /dev/null

Dec 12 10:13:28 Tower kernel: mdcmd (60): spindown 1

Dec 12 10:14:39 Tower kernel: mdcmd (61): spindown 2

Dec 12 10:22:20 Tower emhttp: Spinning down all drives...

Dec 12 10:22:20 Tower kernel: mdcmd (62): spindown 0

Dec 12 10:22:20 Tower kernel: mdcmd (63): spindown 1

Dec 12 10:22:21 Tower kernel: mdcmd (64): spindown 2

Dec 12 10:22:21 Tower kernel: mdcmd (65): spindown 3

Dec 12 10:22:22 Tower kernel: mdcmd (66): spindown 4

Dec 12 10:22:22 Tower emhttp: shcmd (4600): /usr/sbin/hdparm -y /dev/sde &> /dev/null

 

Not sure what to look for at this point, log isn't loud enough (if there is a way to turn it up just for this or if that would even catch the issue).

 

Edit: I have a script in cron now that will run every 5 minutes checking the status of the issue drives using hdparm -C. Tosses it into a log on my cache drive.

 

I've never really nailed down when they are spinning up, as the log doesn't show that usually (maybe never).

Link to post

hm...not sure what to make of this yet, may have to increase my checking from 5 minutes to 1 minute or lower. Below log entries, where sdb = parity drive, sdf = disk 1, sdc = disk 2.

 

 

You can see that at 7:45, sdc/disk2 was in standby. Then between 45 past and 50 past it spun up. Shark tank downloaded at that time in sabnzbd, finished at 7:46. Shark tank season 6 lives exclusively on disk 2 due to my split level. I don't see any new files written to it in the array, but the timing is curious.

 

:

 

Rri Dec 12 19:45:01 PST 2014

/dev/sdb:

drive state is:  standby

 

Fri Dec 12 19:45:01 PST 2014

/dev/sdf:

drive state is:  standby

 

Fri Dec 12 19:45:01 PST 2014

/dev/sdc:

drive state is:  standby

 

Fri Dec 12 19:50:01 PST 2014

/dev/sdb:

drive state is:  standby

 

Fri Dec 12 19:50:01 PST 2014

/dev/sdf:

drive state is:  standby

 

Fri Dec 12 19:50:01 PST 2014

/dev/sdc:

drive state is:  active/idle

Link to post

All my WDC_WD20EARX are not spinning down

hdparm -C /dev/sdd =  drive state is:  active/idle

 

/usr/sbin/smartctl -n standby -A /dev/sd? will yield the same type of output as below.

 

root@Tower:~# smartctl -n standby -A /dev/disk/by-id/ata-WDC_WD20EARX-008FB0_WD-WCAZAH154486
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-3.17.4-unRAID] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:

 

Edited signature with drive spin down information.

 

Looks like the issues is with WD data drives.

 

Link to post

This seems to be a plugin issue in my limited testing so far. Booting into unRAID w/ Xen safe mode does perform a proper spin down as I would expect.

 

Booting into unRAID w/ Xen with a VM running, and apcupsd and powerdown plugins enabled, still exhibit proper spin down behavior. I'm in the process of narrowing down which plugin it is and will report back with my findings. I'm going to mark this as solved as it does not appear to be a core unRAID 6b12 problem.

 

I believe this is a plugin issue but I am still testing to confirm this.

 

Gary

Link to post

Just had all 4 drives spin up this time, had always been drive 1 and drive 2. I use all WD green drives.

 

After hitting a dead end, I had stopped all my dockers but plex during this latest test. Looked good until those drives spun up. I am using the apc plugin as well. Still curious on what is even causing the spin up, although maybe that has always happened and I never noticed it due to the drives spinning down normally after 15 minutes.

 

Thanks for your work GHunter, I would agree that it is an issue outside of corn unraid 6b12.

Link to post

I had all my dockers down today except Plex. Had drive 1 spin up once.

 

Started all my dockers back up just now, drive 1 and drive 2 both spun up immediately.

 

I don't recall if this behavior happened prior to 6b12, but I don't know what in these dockers would want access to the array on start up and why just on disk 1 and 2, the two that refuse to spin down. Checking all my dockers, their paths all refer to /mnt/user/, which I understand to be direct to the cache drive. I use my Media share across all 4 drives. I did change my Media share setting from fill-up to most-free after the upgrade.

 

I've changed it back as a shot in the dark.

 

If I spin up all drives with the unraid drive spinup button and let unraid spin them down 15 minutes later, they do all go down (only tried once myself).

Link to post

Checking all my dockers, their paths all refer to /mnt/user/, which I understand to be direct to the cache drive. I use my Media share across all 4 drives. I did change my Media share setting from fill-up to most-free after the upgrade.

Using /mnt/user means you are going to a user share and thus can always potentially access a disk in the array (if the path that is tried is not one that refers to a cache-only share).    If you really want to go only to the cache disk then you should use the reference to the physical media (e.g. /mnt/cache) instead.

Link to post

Checking all my dockers, their paths all refer to /mnt/user/, which I understand to be direct to the cache drive. I use my Media share across all 4 drives. I did change my Media share setting from fill-up to most-free after the upgrade.

Using /mnt/user means you are going to a user share and thus can always potentially access a disk in the array (if the path that is tried is not one that refers to a cache-only share).    If you really want to go only to the cache disk then you should use the reference to the physical media (e.g. /mnt/cache) instead.

 

 

Ah yes, thanks for the correction. Closer look, I do have a few /mnt/cache entries. I'll get those resolved, suspect that those are the cause of spin ups, which was driving me a bit crazy.

 

Edit: Well I can't change them all, as some of those need access to the array files (like plex and nzbdrone) and nzbdrone had permission issues when using /mnt/cache. My /mnt/user/appdate share is cache only, so I should be good in the regard.

 

Mover ran this morning and disks 1 and 2 didn't spin down.

Link to post

I've got hit by this issue as well, so going back to v5.

 

The summary of my experimenting:

  • I only have WD drives
  • unRAID is completely stock (no plugin and/ or docker), only cache_dirs
  • When running without cache_dirs, disks are spinning down as expected
  • When running with cache_dirs (for the purpose of the testing only with one share, but that share spread across most of the drives), a random set of disks are not spinning down - but I don't think the issue is with cache_dirs, it is just somehow triggering it
  • unRAID tries to spin down those disks as well which keeps spinning, but they keep running
  • unMENU shows them as spun down, so there is inconsistency in disk status between dynamix and unMENU
  • if I force to spin down all disks manually with cache_dirs running, then they stay spun down

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.