December 27, 201411 yr 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.
December 27, 201411 yr 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
December 30, 201411 yr Is there a status update on this issue, maybe a workaround - other than going back to 5.0.6
December 30, 201411 yr 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.
December 30, 201411 yr Author 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.
December 30, 201411 yr 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?
December 30, 201411 yr 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.
December 30, 201411 yr Author Which ones? APC UPS Support Web Virtual Manager Support Dynamix Cache Directories Libvirt Support SNAP Powerdown Package Dynamix System Temperature Dynamix webGui
December 30, 201411 yr 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.
December 30, 201411 yr 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
December 30, 201411 yr I'll be running the same type of script as soana is above. I have removed all plugins but APC UPS. I also realized I didn't have the powerdown plugin anymore, so I've added that now. Not having it previously, I don't expect that to be the cause.
December 30, 201411 yr 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.
December 31, 201411 yr 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.
December 31, 201411 yr 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 ...
December 31, 201411 yr 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.
December 31, 201411 yr 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.
January 2, 201511 yr 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.
January 3, 201511 yr 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.
January 6, 201511 yr 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
January 6, 201511 yr 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.
January 6, 201511 yr 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.
January 6, 201511 yr From what I remembered, emhttp monitored some counters in /proc and/or /sys. If someone can publish where those counters are, then we can see if it's actual access or some other cause.
January 7, 201511 yr 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.
January 7, 201511 yr 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.
January 7, 201511 yr 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.
Archived
This topic is now archived and is closed to further replies.