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


209 posts in this topic Last Reply

Recommended Posts

Same issue.

 

I have 4 EARS (1 EARX which spins down), which after being accessed for any reason (Plex streaming, SMBD, "ls -al", etc) will NOT spin down again.

 

Manually hitting spin down spins them down.

 

Pretty annoying bug to be honest!!

 

I have three docker containers (Plex, SAB, Sick Beard) and one Xen VM running off the cache drive, with all related detain /mnt/cache/VMs/.

 

Also have SSH Plugin installed and all plugins/dockers are up-to-date.

Link to post
  • Replies 208
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

I have one disk that not spin down, it's my parity drive

 

Model Family:	Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model:	WDC WD20EZRX-00DC0B0
Serial Number:	WD-WMC1T0740245

 

BUT this one is OK

 

Model Family:	Western Digital Caviar Green (AF, SATA 6Gb/s)
Device Model:	WDC WD20EARX-00MMMB0
Serial Number:	WD-WCAWZ2744524

Link to post

Is there a status update on this issue, maybe a workaround - other than going back to 5.0.6

 

Can anyone confirm this issue persists on 6b12 without installing the cache dirs plugin or any other 3rd party plugins?  I am not experiencing this issue nor can I recreate it.

Link to post

Is there a status update on this issue, maybe a workaround - other than going back to 5.0.6

 

Can anyone confirm this issue persists on 6b12 without installing the cache dirs plugin or any other 3rd party plugins?  I am not experiencing this issue nor can I recreate it.

 

 

It certainly does it w/o cache_dirs  but I do have other plug-ins that I'd rather not uninstall.

 

 

Link to post

Is there a status update on this issue, maybe a workaround - other than going back to 5.0.6

 

Can anyone confirm this issue persists on 6b12 without installing the cache dirs plugin or any other 3rd party plugins?  I am not experiencing this issue nor can I recreate it.

 

 

It certainly does it w/o cache_dirs  but I do have other plug-ins that I'd rather not uninstall.

 

Which ones?

Link to post

Is there a status update on this issue, maybe a workaround - other than going back to 5.0.6

 

Can anyone confirm this issue persists on 6b12 without installing the cache dirs plugin or any other 3rd party plugins?  I am not experiencing this issue nor can I recreate it.

 

I am using Dynamix Sys Temp, Sys stats, sys info, and apc ups support installed.

 

Other than that, I should be clean of other plugins. Everything else is now either gone or in a docker.

 

Issue continues to be only disk 1 and disk 2, which I had posted model numbers of those drives earlier in this thread.

 

I can do a clean install if needed, but I was holding off for troubleshooting purposes.

Link to post

 

Which ones?

 

 

APC UPS Support

Web Virtual Manager Support

Dynamix Cache Directories

Libvirt Support

SNAP

Powerdown Package

Dynamix System Temperature

Dynamix webGui

 

Well I can't really say for certain if any of those plugins could be impacting this issue.  It would depend on how they function and where relevant data for them is stored and where.

 

I can tell you I'm not having this issue on my systems.  Disks spin down as expected.

Link to post

I can confirm that on my backup server with no plugins the disks stay spun down for about two hours now.

On my regular server where the issue happens I do have the following plugins:

dynamix.kvm.manager.plg ...
virtMan.plg ...
powerdown-x86_64.plg ...
dynamix.system.temp.plg ...
dynamix.system.stats.plg ...
dynamix.system.info.plg ...
dynamix.plg ...
dynamix.cache.dirs.plg ...
dynamix.active.streams.plg ...
Apcupsd-x86_64.plg ...
unRAIDServer.plg ...

 

I will follow two scenarios:

1. on the backup server after 24h I will start adding one plugin at the time and see if the issue appears - will start with cache_dirs first.

2. on my regular server I'm running a script to determine how long it takes for a disk to spin up by itself after a spin down command from gui. The script will run the "hdparm -C /dev/sdx" command every minute for all the disks in the array in an attempt to find a time pattern.

 

<Edit>

Scenario 1 - after ~ 4 hours one WDC disk did spin up (BTW there is no data on this disk) - there was no activity on the backup server and also as I said initially there are no plugins installed on the backup server, also no docker... Johnp do you have any WDC HDD's on your setup?

activity from the processes tab:

root      2740     2  0 11:46 ?        00:00:00 [kworker/1:0]
root      3841     2  0 11:49 ?        00:00:00 [kworker/0:0]
root      4655  1387  0 11:51 ?        00:00:00 sleep 1
root      4656  2438  0 11:51 ?        00:00:00 sh -c cd /usr/local/emhttp; /usr/bin/php /usr/local/src/wrap_get.php webGui/template.php 'path=Tools/Processes&prev=Tools'
root      4657  4656  0 11:51 ?        00:00:00 /usr/bin/php /usr/local/src/wrap_get.php webGui/template.php path=Tools/Processes&prev=Tools
root      4659  4657  0 11:51 ?        00:00:00 ps -ef
root      9177     2  0 10:47 ?        00:00:00 [kworker/1:1]
root     25165     2  0 11:23 ?        00:00:01 [kworker/0:1]

 

Scenario 2 - Disk0 and 1 spun up after 57min at 10:26am the only thing I was able to find in the Processes around that time is:

root      8554     2  0 10:25 ?        00:00:00 [kworker/1:2] 

and

root      8778     2  0 10:26 ?        00:00:00 [kworker/u8:2]

 

Can somebody let me know what the two lines mean?

No entries in the syslog around the same time.

</Edit>

 

Other ideas are welcome.

 

Thank you,

soana

Link to post

How to read KWorker process names. The syntax is "kworker/%u:%d%s (cpu, id, priority)".

 

The u prefix designates a special CPU, the unbound cpu, meaning that the kthread is currently unbound. The workqueue workers which have negative nice value have 'H' postfixed to their names

 

[kworker/1:2]  = cpu 1, id 2

[kworker/u8:2] = unbound cpu, id 2

 

You'll likely want to be running a script that includes "lsof" on /mnt/user/ or /mnt/disk#. That should show better what's happening.

Link to post

Server with plugins

Script:

#!/bin/bash

counter=200
i=1
while [ $counter -gt 0 ]
do
echo "Disk0" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sdb >> /mnt/cache/scripts/tower.log
echo "Disk1" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sdc >> /mnt/cache/scripts/tower.log
echo "Disk2" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sdd >> /mnt/cache/scripts/tower.log
echo "Disk3" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sde >> /mnt/cache/scripts/tower.log
echo "Disk4" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sdf >> /mnt/cache/scripts/tower.log
echo "Disk5" >> /mnt/cache/scripts/tower.log
hdparm -C /dev/sdg >> /mnt/cache/scripts/tower.log
echo "-------------------------------------------" >> /mnt/cache/scripts/tower.log
echo "Disk1" >> /mnt/cache/scripts/tower.log
lsof /mnt/disk1 >> /mnt/cache/scripts/tower.log
echo "Disk2" >> /mnt/cache/scripts/tower.log
lsof /mnt/disk2 >> /mnt/cache/scripts/tower.log
echo "Disk3" >> /mnt/cache/scripts/tower.log
lsof /mnt/disk3 >> /mnt/cache/scripts/tower.log
echo "Disk4" >> /mnt/cache/scripts/tower.log
lsof /mnt/disk4 >> /mnt/cache/scripts/tower.log
echo "Disk5" >> /mnt/cache/scripts/tower.log
lsof /mnt/disk5 >> /mnt/cache/scripts/tower.log
echo "-------------------------------------------" >> /mnt/cache/scripts/tower.log
echo "User" >> /mnt/cache/scripts/tower.log
lsof /mnt/user >> /mnt/cache/scripts/tower.log

date>> /mnt/cache/scripts/tower.log
echo $i " minutes =======================================" >>/mnt/cache/scripts/tower.log

sleep 60s
let i=i+1
done
echo "done!"

 

Output:

/dev/sdb:
drive state is:  active/idle
Disk1

/dev/sdc:
drive state is:  active/idle
Disk2

/dev/sdd:
drive state is:  active/idle
Disk3

/dev/sde:
drive state is:  active/idle
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
COMMAND  PID USER   FD   TYPE DEVICE   SIZE/OFF   NODE NAME
shfs    3339 root    4r   REG    9,1 1269029912 201395 /mnt/disk1/Media/Movies/My Movies/A Cinderella Story (2004)/A Cinderella Story (2004).mkv
Disk2
COMMAND  PID USER   FD   TYPE DEVICE  SIZE/OFF NODE NAME
shfs    3339 root    5r   REG    9,2 533144394 2121 /mnt/disk2/Media/TV Shows/Gilmore Girls/Season 6/S06E04 - Always a Godmother, Never a God.mkv
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID   USER   FD   TYPE DEVICE   SIZE/OFF  NODE NAME
find     2134   root  cwd    DIR   0,27        912 33834 /mnt/user/Backup/Computers/Sony Vaio (TBD)/UserRocBackup/AppData/Local/Mozilla/Firefox/Profiles/cbc6b6py.default/Cache/A
smbd     4796 nobody   26r   DIR   0,27        184     8 /mnt/user/MyMedia
smbd    17711 nobody  cwd    DIR   0,27        192     5 /mnt/user/Media
smbd    17711 nobody   11r   REG   0,27  533144394  5013 /mnt/user/Media/TV Shows/Gilmore Girls/Season 6/S06E04 - Always a Godmother, Never a God.mkv
smbd    18808 nobody  cwd    DIR   0,27        192     5 /mnt/user/Media
smbd    18808 nobody   11r   REG   0,27 1269029912 81452 /mnt/user/Media/Movies/My Movies/A Cinderella Story (2004)/A Cinderella Story (2004).mkv
Tue Dec 30 20:30:21 EST 2014
23  minutes =======================================

 

The only items suspect so far seem to be:

find     2134   root  cwd    DIR   0,27        912 33834 /mnt/user/Backup/Computers/Sony Vaio (TBD)/UserRocBackup/AppData/Local/Mozilla/Firefox/Profiles/cbc6b6py.default/Cache/A
smbd     4796 nobody   26r   DIR   0,27        184     8 /mnt/user/MyMedia

 

Running the same script on the backup server (no plugins) - will report back if anything shows up in the log.

 

 

Link to post

This morning 5:56am I decided to remove the cache_dir and to manually spin down all the disks.

All were in standby until 9:14am when Disk0 (parity) and Disk1 did spin up bellow is the output of my script for that time:

removed cache_dirs plugin 
spin down disks


Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND  PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    4796 nobody   26r   DIR   0,27      184    8 /mnt/user/MyMedia
smbd    4796 nobody   37r   DIR   0,27      544    2 /mnt/user/Backup
Wed Dec 31 05:56:30 EST 2014
585  minutes =======================================
.
.
.REMOVED - SAME OUTPUT
.
.
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    4796 root   26r   DIR   0,27      184    8 /mnt/user/MyMedia
smbd    4796 root   37r   DIR   0,27      544    2 /mnt/user/Backup
Wed Dec 31 08:23:31 EST 2014
731  minutes =======================================
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
Wed Dec 31 08:24:31 EST 2014
732  minutes =======================================
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
Wed Dec 31 08:25:31 EST 2014
733  minutes =======================================
.
.
.REMOVED - SAME OUTPUT
.
.
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
Wed Dec 31 09:03:46 EST 2014
771  minutes =======================================
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 nobody   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:04:47 EST 2014
772  minutes =======================================
.
.
.REMOVED - SAME OUTPUT
.
.
.
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 root   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:13:51 EST 2014
781  minutes =======================================
Disk0

/dev/sdb:
drive state is:  active/idle
Disk1

/dev/sdc:
drive state is:  active/idle
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 root   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:14:51 EST 2014
782  minutes =======================================
.
.
.REMOVED - SAME OUTPUT
.
.
.
Disk0

/dev/sdb:
drive state is:  active/idle
Disk1

/dev/sdc:
drive state is:  active/idle
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 root   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:44:03 EST 2014
811  minutes =======================================
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  active/idle
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 root   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:45:03 EST 2014
812  minutes =======================================
Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  active/idle
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  standby
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
smbd    15535 root   31r   DIR   0,27      184    8 /mnt/user/MyMedia
Wed Dec 31 09:46:04 EST 2014
813  minutes =======================================

 

also added the processes:

root      7612     2  0 08:23 ?        00:00:02 [kworker/0:0]
root      8092     2  0 08:26 ?        00:00:00 [kworker/u8:1]
root     12166     2  0 08:46 ?        00:00:01 [kworker/3:2]
root     15535  1388  0 09:04 ?        00:00:00 /usr/sbin/smbd -D
root     16986     2  0 09:11 ?        00:00:00 [kworker/1:0]
root     19487     2  0 09:23 ?        00:00:01 [kworker/0:1]
root     19922  1335  0 09:26 ?        00:00:00 in.telnetd: 192.168.0.2                                                                                                                                                                                                                                                                                                                
root     19923 19922  0 09:26 pts/0    00:00:00 -bash
root     19960 19923  0 09:26 pts/0    00:00:00 less
root     19983     2  0 09:26 ?        00:00:00 [kworker/u8:2]
root     21603     2  0 05:21 ?        00:00:00 [kworker/1:2]
root     22031     2  0 09:32 ?        00:00:00 [kworker/2:1]
root     22882     2  0 09:34 ?        00:00:00 [kworker/2:3]
root     25324     2  0 04:21 ?        00:00:00 [kworker/3:0]
root     25578     2  0 09:41 ?        00:00:00 [kworker/u8:0]
root     26160     2  0 09:42 ?        00:00:00 [kworker/2:0]
root     27241     2  0 09:45 ?        00:00:00 [kworker/u8:3]
root     27375     2  0 09:45 ?        00:00:00 [kworker/2:2]
root     28988 17516  0 09:50 tty1     00:00:00 sleep 60s
root     29187  3157  0 09:50 ?        00:00:00 sh -c cd /usr/local/emhttp; /usr/bin/php /usr/local/src/wrap_get.php webGui/template.php 'path=Tools/Processes&prev=Tools'
root     29188 29187  0 09:50 ?        00:00:00 /usr/bin/php /usr/local/src/wrap_get.php webGui/template.php path=Tools/Processes&prev=Tools
root     29191  1393  0 09:50 ?        00:00:00 sleep 1
root     29192 29188  0 09:50 ?        00:00:00 ps -ef

 

At 9:44am Disk0 did spin down as per the 30min set in the GUI page but Disk1 is still spinning...

 

Not sure what to do next.

 

Plugins currently on the server:

plugin: checking dynamix.kvm.manager.plg ...
plugin: checking virtMan.plg ...
plugin: checking powerdown-x86_64.plg ...
plugin: checking dynamix.system.temp.plg ...
plugin: checking dynamix.system.stats.plg ...
plugin: checking dynamix.system.info.plg ...
plugin: checking dynamix.plg ...
plugin: checking dynamix.active.streams.plg ...
plugin: checking Apcupsd-x86_64.plg ...
plugin: checking unRAIDServer.plg ...

 

Link to post

Is lsof expected to not list files being played, say a song that resides on the array? Thought a file being played would be considered open, but lsof doesn't show anything being touched in /mnt/user or /mnt/disk1 (where the song lives). lsof does catch me going into a directory though.

 

My lsof check also died for some reason at 8pm last night. I am re-running it now.

 

After I stopped watching shows my parity drive, disk 1 and disk 2 stayed spun up all night. Disk 1 then spun down at 7am:

 

Dec 31 07:24:22 Tower kernel: mdcmd (534): spindown 4

Dec 31 07:24:33 Tower kernel: mdcmd (535): spindown 1

Dec 31 07:24:33 Tower kernel: mdcmd (536): spindown 2

 

If the numbers after these are equal to disk numbers, I have no clue why 4 was in the mix as I am not monitoring that one due to not seeing an issue with it.

 

 

Edit: From my song play test, disk 1 tried to spin down:

 

Dec 31 11:06:17 Tower kernel: mdcmd (542): spindown 1

 

But continues to be up and lsof didn't catch a single thing. I don't know what else to look for as to why this disk wouldn't spin down.

Link to post

active dockers: Plex

plug-ins installed: Powerdown, Snap (nothing connected), Dynamix System Statistics, Dynamix System Information, Dynamix webGui, Dynamix Active Streams

1 share includes all array disks (see pic for settings).

 

No rhyme or reason as to which drive stays awake other than the 3 I expect to be up. I would expect 1 & 2 to be active (and cache) as they are the only ones with space left for writes. Currently running Plex cloud sync from title on disk 2. Note disk 10 shows traffic but that is from yesterday when I cloud sync'd an older title. The rest have no business being awake.

Screenshot_1.png.774ee1edc980545287425c34cfdbf4d9.png

Screenshot_2.png.bde8ce4026653362ac63caaf11885acb.png

Link to post

Hi all,

 

I'm also experiencing spin down issues. Fresh install of 6.0-beta12 with no plugins installed.

 

Once in a while parity disk (SAMSUNG) doesn't spin down. Data drive (WD Green) actually spins down with no issue.

 

root@littlemamba:~# hdparm -C /dev/sdc

 

/dev/sdc:

drive state is:  active/idle

root@littlemamba:~# hdparm -C /dev/sdb

 

/dev/sdb:

drive state is:  standby

 

lsof doesn't show anything open pointing to /mnt/disk1, and I'm only using unraid at the moment to publish 2 Samba shares.

 

Jan  1 21:59:09 littlemamba kernel: PM: resume of devices complete after 11036.027 msecs

Jan  1 21:59:09 littlemamba kernel: Restarting tasks ... done.

Jan  1 21:59:09 littlemamba kernel: forcedeth 0000:00:0a.0 eth0: link down

Jan  1 21:59:12 littlemamba kernel: forcedeth 0000:00:0a.0 eth0: link up

Jan  1 21:59:50 littlemamba crond[1247]: time disparity of 99 minutes detected

Jan  1 22:05:54 littlemamba emhttp: sendFile: sendfile /usr/local/emhttp/plugins/dynamix/images/confirmations.png: Broken pipe

Jan  1 22:05:54 littlemamba emhttp: sendFile: sendfile /usr/local/emhttp/plugins/dynamix/images/scheduler.png: Broken pipe

Jan  1 22:05:54 littlemamba emhttp: sendFile: sendfile /usr/local/emhttp/plugins/dynamix/images/notifications.png: Broken pipe

Jan  2 01:22:30 littlemamba kernel: mdcmd (35): spindown 1

Jan  2 10:45:19 littlemamba sshd[3377]: Accepted password for root

 

root@littlemamba:~# hdparm -i /dev/sdc

 

/dev/sdc:

 

Model=SAMSUNG HD204UI, FwRev=1AQ10001, SerialNo=S2H7J9CB501910

Config={ Fixed }

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4

BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off

CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=3907029168

IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes:  pio0 pio1 pio2 pio3 pio4

DMA modes:  mdma0 mdma1 mdma2

UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6

AdvancedPM=yes: disabled (255) WriteCache=enabled

Drive conforms to: unknown:  ATA/ATAPI-0,1,2,3,4,5,6,7

 

* signifies the current active mode

 

root@littlemamba:~# hdparm -i /dev/sdb

 

/dev/sdb:

 

Model=WDC WD15EADS-00P8B0, FwRev=01.00A01, SerialNo=WD-WMAVU0561258

Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }

RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50

BuffType=unknown, BuffSize=unknown, MaxMultSect=16, MultSect=off

CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=2930277168

IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}

PIO modes:  pio0 pio3 pio4

DMA modes:  mdma0 mdma1 mdma2

UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6

AdvancedPM=no WriteCache=enabled

Drive conforms to: Unspecified:  ATA/ATAPI-1,2,3,4,5,6,7

 

* signifies the current active mode

 

Thanks,

anthonws.

Link to post

My lsof/while command kept crashing while running in the background for some reason. I even put it in as an infinite loop and it still didn't want to stay up.

 

So finding what was a.) causing the spin up, as I have no idea what was trying to even access the array at times (like when no one was home during the day, no mover, no streaming) and b.) what was causing the spin down not to work, was proving difficult. The times the lsof command stayed up I saw nothing open on the array outside of what I was streaming.

 

I've downgraded back to b10a. After 15 minutes, all disks spun down, in order, without my intervention. The main reason for me going to b12 was for the dynamix graphs, but since historical never worked for me (I could only view in real time), they weren't very useful.

 

I'll be sticking with b10a for the near future and keep a close watch on this thread for any developments.

Link to post

Just cannot figure out what's happening.

 

The latest test I did was to spin-up all drives and then wait for the 15minute to kick-in.

After this time all disks did spin down with the exception of disk5.

 

below is the output for hdparm -C /dev/sdx, lsof /mnt/diskx and lsof /mnt/user (per my script)

 

Disk0

/dev/sdb:
drive state is:  standby
Disk1

/dev/sdc:
drive state is:  standby
Disk2

/dev/sdd:
drive state is:  standby
Disk3

/dev/sde:
drive state is:  standby
Disk4

/dev/sdf:
drive state is:  standby
Disk5

/dev/sdg:
drive state is:  active/idle
-------------------------------------------
Disk1
Disk2
Disk3
Disk4
Disk5
-------------------------------------------
User
Mon Jan  5 21:38:59 EST 2015
31  minutes =======================================

 

syslog does show:

 

Jan  5 21:28:56 Tower kernel: mdcmd (139): spindown 0
Jan  5 21:28:56 Tower kernel: mdcmd (140): spindown 1
Jan  5 21:28:57 Tower kernel: mdcmd (141): spindown 2
Jan  5 21:28:58 Tower kernel: mdcmd (142): spindown 3
Jan  5 21:28:59 Tower kernel: mdcmd (143): spindown 4
Jan  5 21:28:59 Tower kernel: mdcmd (144): spindown 5

Link to post

The primary issue here is that we haven't been able to recreate this in our lab at all.  Granted, we do NOT use all the plugins that everyone here uses.  I can't say whether a plugin should or shouldn't impact this because we honestly haven't reviewed the code for many of the plugins in reference.

 

The expected behavior with spin up / down is that if there is nothing accessing the disk, it shouldn't spin up.  The only thing that should trigger a spin up is when data is accessed on the device in question.  That said, there are some significant changes to the webUI that we will be pushing out soon that MAY impact this, but can't say for certain yet.  Once the new update is available, I will check back with folks in this thread to see if these weird spinup / spin downs exist.

 

I can confirm that we have some WD Greens spread throughout our testing environment.

 

The biggest help will come from users who have a vanilla unRAID 6 install with no plugins, containers, or VMs installed.  For these folks, if you can consistently recreate the issue, we've narrowed this down to something either hardware specific or unRAID specific as the culprit.  If you are running ANY plugins, we can't say for certain what the cause might be.

Link to post

The biggest help will come from users who have a vanilla unRAID 6 install with no plugins, containers, or VMs installed.  For these folks, if you can consistently recreate the issue, we've narrowed this down to something either hardware specific or unRAID specific as the culprit.  If you are running ANY plugins, we can't say for certain what the cause might be.

 

I am just getting concerned reading this. I think you would need to deal with the issue even if it is caused by a plugin. In case the same plugin(s) was working before, I don't think it would be nice to blame the plugin. Especially not a plugin like cache_dirs what was proven to work for ages. So even in case spinup/ spin down works as expected on vanilla unRAID 6, but not for example with cache_dirs, I think the bug hunting efforts should focus on unRAID figuring out why and not on the cache_dirs side of things.

 

Personally I beleive it will be somehow related with some background SMART polling/ disk health monitoring - now this is all integrated, could these by somehow manually disabled for testing?

 

I think Jon you know pretty much as well that the number of reports on this are just too many to consider it some random user/ usage issue. Especially taken into consideration that reports are coming from long time, experienced users who use unRAID for years.

Link to post

 

 

The biggest help will come from users who have a vanilla unRAID 6 install with no plugins, containers, or VMs installed.  For these folks, if you can consistently recreate the issue, we've narrowed this down to something either hardware specific or unRAID specific as the culprit.  If you are running ANY plugins, we can't say for certain what the cause might be.

 

I am just getting concerned reading this. I think you would need to deal with the issue even if it is caused by a plugin. In case the same plugin(s) was working before, I don't think it would be nice to blame the plugin. Especially not a plugin like cache_dirs what was proven to work for ages. So even in case spinup/ spin down works as expected on vanilla unRAID 6, but not for example with cache_dirs, I think the bug hunting efforts should focus on unRAID figuring out why and not on the cache_dirs side of things.

 

Personally I beleive it will be somehow related with some background SMART polling/ disk health monitoring - now this is all integrated, could these by somehow manually disabled for testing?

 

I think Jon you know pretty much as well that the number of reports on this are just too many to consider it some random user/ usage issue. Especially taken into consideration that reports are coming from long time, experienced users who use unRAID for years.

 

Bottom line is that if we cannot recreate the issue on a test system, we have no issue to fix.

 

Second bottom line is that we are not responsible for any plugins that break between software releases. If we don't write the code, we are not going to review the code between releases or even test the plugins.  The only things we test between releases is the core functionality we provide.  We never intentionally do things to break plugins, but sometimes that does happen.

 

Even cache dirs had to go through some major changes to be adapted to v6 and I wouldn't go so far to say that plugin is 100% perfect just yet.  I don't have it installed on my test systems at this time. 

 

And again, we didn't write the code, and if the plugin is installed and an issue happens that doesn't occur with it not installed, I suggest you take the issue up with the plugin author.

 

At some point, cache dirs is a feature we want to implement as an official part of the build, but it falls in the category of optimization, not a core feature that we have to implement right this very second.

 

Just trying to be very open and honest about our approach to development here.  Plugins are community developed and community supported.  Sometimes those plugins get merged into the base, sometimes they don't.  But until a plugin is officially adopted, support for it has to be on the community to provide.

 

 

Link to post

Tapatalk is messing up on my phone tonight!  Argh!

 

I just wanted to add that I'm also not convinced this issue is the source of a plugin problem.  But it goes back to what I said earlier.  If we can't recreate it in the lab, there is nothing for us to fix.

Link to post

I was able to recreate tonight on one of my test machines at home.  This is the FOURTH machine I've tested on.  Good news is that on an internal development build, I'm NOT having this issue anymore, so I think some of the lower level changes we made in this build internally just happened to fix it.  Crossing my fingers on this, but until the next release is pushed out and we get feedback from folks here, we won't know for sure.  At least it looks like there is light at the end of the tunnel.

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.