March 28, 201412 yr I just finished setting up my first unRaid server. Installed Dynamix, put all data on disks, the only thing that is still missing is to install the parity disk (waiting for more cables, stupid parcels gone missing). So I copied some stuff to my cache disk last night, enabled shutdown in Dynamix when array is inactive but this morning the PC is still running. One disk is still spinning, even though no other device is online at night in my household. Also this disk is excluded from all shares but one for time machine (which also isn't configured yet on any Mac). It's a WD Green 1.5TB, so a little bit older. It is connected to the same onBoard SATA Controller as the rest, only the Cache disk is connected to an external controller, but that one is spun down. There also have been no writes to the disk (just 7 writes for whatever reason since booting up). How can I debug this? I need the server to go to sleep, but I can't fully exclude the disk in case a backup is running in the future.
March 28, 201412 yr Author Is there a way to disable it, without losing all the configuration? Also I checked the syslog, I see some errors that I don't know the meaning to: Mar 27 20:46:22 Tower kernel: mdcmd (39): spindown 5 Mar 27 20:51:09 Tower kernel: mdcmd (40): spindown 4 Mar 27 20:51:21 Tower kernel: mdcmd (41): spindown 1 Mar 27 20:51:22 Tower kernel: mdcmd (42): spindown 2 Mar 27 20:51:23 Tower kernel: mdcmd (43): spindown 3 Mar 27 20:55:33 Tower kernel: ata8.00: exception Emask 0x10 SAct 0x0 SErr 0x5801 00 action 0x6 Mar 27 20:55:33 Tower kernel: ata8.00: irq_stat 0x08000000 Mar 27 20:55:33 Tower kernel: ata8: SError: { UnrecovData 10B8B Dispar Handshk } Mar 27 20:55:33 Tower kernel: ata8.00: failed command: WRITE DMA EXT Mar 27 20:55:33 Tower kernel: ata8.00: cmd 35/00:00:98:e4:eb/00:04:16:00:00/e0 t ag 0 dma 524288 out Mar 27 20:55:33 Tower kernel: res 50/00:00:97:e4:eb/00:00:16:00:00/e0 E mask 0x10 (ATA bus error) Mar 27 20:55:33 Tower kernel: ata8.00: status: { DRDY } Mar 27 20:55:33 Tower kernel: ata8: hard resetting link Mar 27 20:55:34 Tower kernel: ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 27 20:55:34 Tower kernel: ata8.00: configured for UDMA/133 Mar 27 20:55:34 Tower kernel: ata8: EH complete Mar 27 21:00:01 Tower logger: mover started disk 5 is the disk in question, so at least at one time it was send a spindown command. This error happens later again, during an active mover script (it's copying stuff from the cache disk to another disk Mar 27 21:24:02 Tower logger: >f+++++++++ files/misc/Barbara/Bar bara - S\#303\#274\#303\#237er 18j\#303\#244hriger!.wmv Mar 27 21:24:19 Tower kernel: ata8.00: exception Emask 0x10 SAct 0x0 SErr 0x5801 00 action 0x6 Mar 27 21:24:19 Tower kernel: ata8.00: irq_stat 0x08000000 Mar 27 21:24:19 Tower kernel: ata8: SError: { UnrecovData 10B8B Dispar Handshk } Mar 27 21:24:19 Tower kernel: ata8.00: failed command: WRITE DMA EXT Mar 27 21:24:19 Tower kernel: ata8.00: cmd 35/00:00:28:3d:b1/00:04:1f:00:00/e0 t ag 0 dma 524288 out Mar 27 21:24:19 Tower kernel: res 50/00:00:27:3d:b1/00:00:1f:00:00/e0 E mask 0x10 (ATA bus error) Mar 27 21:24:19 Tower kernel: ata8.00: status: { DRDY } Mar 27 21:24:19 Tower kernel: ata8: hard resetting link Mar 27 21:24:19 Tower kernel: ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 27 21:24:19 Tower kernel: ata8.00: configured for UDMA/133 Mar 27 21:24:19 Tower kernel: ata8: EH complete Not sure if it's related to the file name. Anyway, later at night when the mover is finished, disk 5 is not send a spindown: Mar 28 00:00:01 Tower logger: mover finished Mar 28 00:12:50 Tower emhttp: shcmd (1343): /usr/sbin/hdparm -y /dev/sdh &> /dev /null Mar 28 00:14:20 Tower kernel: mdcmd (50): spindown 1 Mar 28 00:14:42 Tower kernel: mdcmd (51): spindown 2 Mar 28 00:14:54 Tower kernel: mdcmd (52): spindown 3 Mar 28 00:14:56 Tower kernel: mdcmd (53): spindown 4 Mar 28 00:29:30 Tower sSMTP[6067]: Creating SSL connection to host So /dev/sdh is the cache disk, and all other disks are spindown except disk 5. That was 7 hours ago. I just did a manual spindown using the UI and it send a spindown command to all disks and then it worked. So I'm still unsure on why disk 5 was missed during a time at which no other machine on the network was alive (except the router but this is blocking all incoming connections from the outside). And it was never issued a spindown command again this night.
March 28, 201412 yr Boot the array in Safe Mode -- I believe that will just load the stock GUI Then let it run like that to see if it changes the spindown behavior
March 28, 201412 yr ata8: SError: { UnrecovData 10B8B Dispar Handshk } This indicates a bad or loose SATA cable.
March 28, 201412 yr Author I will try booting safe mode tonight and see if it changes anything. The SATA cable is giving me headaches though. Why doesn't it list which port it is, or am I blind? I could write to all disks without errors though. And the parity disk is already connected but not yet in the array. I have spare cables at home but how do I know which to exchange? I have 6 Ports on the Mainboard and an external Controller with additional 2 Ports (only one populated though by the cache drive).
March 28, 201412 yr Author So I'm at home now, I haven't seen the SATA errors anymore in the syslog, but I figured out which disk it was that made those errors - it's the cache drive on the external controller. Anyway, I did monitor closely the log file and the array and I could see that a spindown command was issued for disk 5 but it just doesn't spin down! Mar 28 17:04:19 Tower logger: mover finished Mar 28 17:12:05 Tower kernel: mdcmd (39): spindown 5 Mar 28 17:19:36 Tower kernel: mdcmd (40): spindown 1 Mar 28 17:19:37 Tower kernel: mdcmd (41): spindown 2 Mar 28 17:19:38 Tower kernel: mdcmd (42): spindown 3 Mar 28 17:19:39 Tower emhttp: shcmd (114): /usr/sbin/hdparm -y /dev/sdh &> /dev/null Mar 28 17:19:59 Tower kernel: mdcmd (43): spindown 4 All other drives are off, but this one stays on for whatever reason. root@Tower:~# lsscsi [0:0:0:0] disk SanDisk Cruzer Fit 1.27 /dev/sda [1:0:0:0] disk ATA WDC WD40EZRX-00S 80.0 /dev/sdb [2:0:0:0] disk ATA WDC WD40EZRX-00S 80.0 /dev/sdc [3:0:0:0] disk ATA WDC WD40EZRX-00S 80.0 /dev/sdd [4:0:0:0] disk ATA WDC WD40EFRX-68W 80.0 /dev/sde [5:0:0:0] disk ATA WDC WD15EARS-00M 51.0 /dev/sdf <--- That's the one! [6:0:0:0] disk ATA WDC WD40EZRX-00S 80.0 /dev/sdg [8:0:0:0] disk ATA WDC WD5000AAKS-6 12.0 /dev/sdh I then issued a manual spindown command using the GUI. It took a couple of seconds but then it successfully spun down. That's so weird. I suspect that unRaid only issues a spindown command once and then it just assumes that the drive is offline and doesn't check it again, that's why the PC was running the whole night. Since disk 5 is not yet used for anything it couldn't have been some process writing to it. I created a Time Machine share on it, and excluded it from all other SMB shares since it should be used exclusively for Time Machine in the future. Any idea how else I can debug it? EDIT: I also booted unRaid now into Safe Mode, running the Stock UI, it send the spindown command after 15 Minutes, although for some reason, disk 5 received the command a couple of seconds later: Mar 28 17:58:59 Tower kernel: mdcmd (39): spindown 1 Mar 28 17:59:01 Tower kernel: mdcmd (40): spindown 2 Mar 28 17:59:02 Tower kernel: mdcmd (41): spindown 3 Mar 28 17:59:04 Tower kernel: mdcmd (42): spindown 4 Mar 28 17:59:06 Tower emhttp: shcmd (174): /usr/sbin/hdparm -y /dev/sdh &> /dev/null Mar 28 17:59:27 Tower kernel: mdcmd (43): spindown 5 And it started blinking, like the other drives, so I think it really spun down. That's weird. Maybe it is Dynamix related after all?
March 28, 201412 yr Author Ok now again with Dynamix GUI, it sends a spindown command but it doesn't spin down. Mar 28 18:18:41 Tower kernel: mdcmd (39): spindown 5 Mar 28 18:21:32 Tower kernel: mdcmd (40): spindown 1 Mar 28 18:22:03 Tower kernel: mdcmd (41): spindown 2 Mar 28 18:23:34 Tower kernel: mdcmd (42): spindown 3 Mar 28 18:24:05 Tower kernel: mdcmd (43): spindown 4 Mar 28 18:24:06 Tower emhttp: shcmd (118): /usr/sbin/hdparm -y /dev/sdh &> /dev/null And it's still running.... No open files when using lsof like dgaschk suggested. Every command returned nothing. It's essentially the same command that is being send, the UI shouldn't have anything to do with, now should it? I really like and need Dynamix for various plugins / reason. Sad thing is, Sleep S3 is one of em and it doesn't work unless all disks get send to sleep I can manually spin it down, np: root@Tower:~# hdparm -C /dev/sdf /dev/sdf: drive state is: active/idle root@Tower:~# hdparm -y /dev/sdf /dev/sdf: issuing standby command root@Tower:~# hdparm -C /dev/sdf /dev/sdf: drive state is: standby This is driving me nuts. edit: going even more crazy. Now I'm using another disk to copy stuff across and what happens, of course disk 5 is going to sleep... edit 2: Ok, after even more observation while running Dynamix, I can see that this is happening to other drives as well - so it's probably not the drives' fault. I'm copying data across to disk 4 and disk 5 (still no parity installed) and then disk 1 woke up on it's own, later disk 2 and 3 followed - nobody accessed those drives. SMART checks of spundown disks are disabled. After 15 minutes the spindown command for disk 1 through 3 was issued, only 2 and 3 really went to sleep. disk1 is continuing to run and never had a single read or write. and its temperature is increasing too. That's why I bought unRaid in the first place, because it should only power disks in use and put them back to sleep, but apparently it's not working at all. I still can't believe that Dynamix is responsible, but I will do more tests while in safe-mode later on.
March 28, 201412 yr I still can't believe that Dynamix is responsible, but I will do more tests while in safe-mode later on. It may not be, but the best way to confirm that is to run a "stock" UnRAID using the built-in Web GUI and confirm that the behavior is either the same, or that it works okay in that environment. Then you'll know whether this is an UnRAID issue or an issue with the set of plugins you're using.
March 29, 201412 yr Two things that can affect spin ups, in sometimes unexpected ways, are spinup groups and Cache_dirs. Check your spinup group settings, make sure each disk has a unique 'host' name. If you are using Cache_dirs, make sure it is set to monitor as few folders as you actually need it to monitor. Too many and it will have to reload under heavier I/O, causing some drives to spin up, typically low numbered drives. not worded well, but don't have any time just now
Archived
This topic is now archived and is closed to further replies.