March 6, 201016 yr Upgrade unraid image to 4.5.3 and experience some strange disk spin down issue that i never observed before. As we can see from this syslog output, some disk, for example disk 4, were spin down too frequently within short period of time . this happen while i was copying data from disk 7 to disk15 and copying data from an unprotected disk in my unraid box to an outside box. I also have cache_dir running at my unRaid, right after i killed this process, i no longer observe this strange spindown behavior, is that because new unRaid image now has conflict with cache_dir process? spin down delay is 1 hour and spinup group is enabled. cache_dir version 1.6.4 ----------------------------------------------------------------------------------------------------------------------------------- Mar 6 09:15:36 Tower kernel: mdcmd (5400): spindown 8 Mar 6 09:15:46 Tower kernel: mdcmd (5402): spindown 9 Mar 6 09:15:54 Tower kernel: mdcmd (5403): spindown 12 Mar 6 09:16:04 Tower kernel: mdcmd (5405): spindown 12 Mar 6 09:16:04 Tower kernel: mdcmd (5406): spindown 13 Mar 6 09:16:10 Tower kernel: mdcmd (5409): spindown 14 Mar 6 09:16:21 Tower kernel: mdcmd (5412): spindown 14 Mar 6 09:32:33 Tower kernel: mdcmd (5527): spindown 4 Mar 6 09:32:44 Tower kernel: mdcmd (5531): spindown 4 Mar 6 09:32:45 Tower kernel: mdcmd (5532): spindown 5 Mar 6 09:32:55 Tower kernel: mdcmd (5535): spindown 4 Mar 6 09:32:55 Tower kernel: mdcmd (5536): spindown 5 Mar 6 09:32:56 Tower kernel: mdcmd (5537): spindown 6 Mar 6 09:33:06 Tower kernel: mdcmd (5539): spindown 6 Mar 6 09:33:07 Tower kernel: mdcmd (5540): spindown 9 Mar 6 09:33:17 Tower kernel: mdcmd (5542): spindown 12 Mar 6 09:33:24 Tower kernel: mdcmd (5546): spindown 13 Mar 6 09:33:44 Tower kernel: mdcmd (5549): spindown 5 Mar 6 09:33:44 Tower kernel: mdcmd (5550): spindown 13 Mar 6 09:33:45 Tower kernel: mdcmd (5551): spindown 14 Mar 6 09:36:45 Tower kernel: mdcmd (5573): spindown 4 Mar 6 09:36:55 Tower kernel: mdcmd (5575): spindown 4 Mar 6 09:36:56 Tower kernel: mdcmd (5576): spindown 5 Mar 6 09:37:06 Tower cache_dirs: killing cache_dirs process 5560 Mar 6 09:37:06 Tower kernel: mdcmd (5578): spindown 5 Mar 6 09:37:07 Tower kernel: mdcmd (5579): spindown 6 Mar 6 09:37:17 Tower kernel: mdcmd (5582): spindown 9 Mar 6 09:37:25 Tower kernel: mdcmd (5584): spindown 12 Mar 6 09:37:35 Tower kernel: mdcmd (5586): spindown 12 Mar 6 09:37:35 Tower kernel: mdcmd (5587): spindown 13 Mar 6 09:37:41 Tower kernel: mdcmd (5589): spindown 14 Mar 6 09:37:52 Tower kernel: mdcmd (5592): spindown 14
March 8, 201016 yr I suspect I also had some weird spindown issues, unfortunately I rebooted before investigating. Was also running cache_dirs.
March 11, 201016 yr Upgrade unraid image to 4.5.3 and experience some strange disk spin down issue that i never observed before. As we can see from this syslog output, some disk, for example disk 4, were spin down too frequently within short period of time . this happen while i was copying data from disk 7 to disk15 and copying data from an unprotected disk in my unraid box to an outside box. I also have cache_dir running at my unRaid, right after i killed this process, i no longer observe this strange spindown behavior, is that because new unRaid image now has conflict with cache_dir process? spin down delay is 1 hour and spinup group is enabled. cache_dir version 1.6.4 Mar 6 09:15:36 Tower kernel: mdcmd (5400): spindown 8 Mar 6 09:15:46 Tower kernel: mdcmd (5402): spindown 9 Mar 6 09:15:54 Tower kernel: mdcmd (5403): spindown 12 Mar 6 09:16:04 Tower kernel: mdcmd (5405): spindown 12 Mar 6 09:16:04 Tower kernel: mdcmd (5406): spindown 13 Mar 6 09:16:10 Tower kernel: mdcmd (5409): spindown 14 Mar 6 09:16:21 Tower kernel: mdcmd (5412): spindown 14 Mar 6 09:32:33 Tower kernel: mdcmd (5527): spindown 4 Mar 6 09:32:44 Tower kernel: mdcmd (5531): spindown 4 Mar 6 09:32:45 Tower kernel: mdcmd (5532): spindown 5 Mar 6 09:32:55 Tower kernel: mdcmd (5535): spindown 4 Mar 6 09:32:55 Tower kernel: mdcmd (5536): spindown 5 Mar 6 09:32:56 Tower kernel: mdcmd (5537): spindown 6 Mar 6 09:33:06 Tower kernel: mdcmd (5539): spindown 6 Mar 6 09:33:07 Tower kernel: mdcmd (5540): spindown 9 Mar 6 09:33:17 Tower kernel: mdcmd (5542): spindown 12 Mar 6 09:33:24 Tower kernel: mdcmd (5546): spindown 13 Mar 6 09:33:44 Tower kernel: mdcmd (5549): spindown 5 Mar 6 09:33:44 Tower kernel: mdcmd (5550): spindown 13 Mar 6 09:33:45 Tower kernel: mdcmd (5551): spindown 14 Mar 6 09:36:45 Tower kernel: mdcmd (5573): spindown 4 Mar 6 09:36:55 Tower kernel: mdcmd (5575): spindown 4 Mar 6 09:36:56 Tower kernel: mdcmd (5576): spindown 5 Mar 6 09:37:06 Tower cache_dirs: killing cache_dirs process 5560 Mar 6 09:37:06 Tower kernel: mdcmd (5578): spindown 5 Mar 6 09:37:07 Tower kernel: mdcmd (5579): spindown 6 Mar 6 09:37:17 Tower kernel: mdcmd (5582): spindown 9 Mar 6 09:37:25 Tower kernel: mdcmd (5584): spindown 12 Mar 6 09:37:35 Tower kernel: mdcmd (5586): spindown 12 Mar 6 09:37:35 Tower kernel: mdcmd (5587): spindown 13 Mar 6 09:37:41 Tower kernel: mdcmd (5589): spindown 14 Mar 6 09:37:52 Tower kernel: mdcmd (5592): spindown 14 I don't use cache_dirs, and I too saw this problem. It's been reported by other people too. http://lime-technology.com/forum/index.php?topic=5595.msg52119#msg52119 ...spin down delay is 1 hour... Then consecutive spindown attempts should be no less than an hour apart. Certainly not 10 seconds apart! Email Limetech, and point them to your thread.
July 6, 201016 yr Correction: Limetech have declared that spinning down hard disks every 10 seconds is NOT a bug. http://lime-technology.com/forum/index.php?topic=6870.msg66897#msg66897 So please, don't email them at [email protected] or I'll be blamed for instigating customers to report their bugs. Thank you. - - - edit: To those who took the above literlly and messaged me:
July 6, 201016 yr Author Correction: Limetech have declared that spinning down hard disks every 10 seconds is NOT a bug. http://lime-technology.com/forum/index.php?topic=6870.msg66897#msg66897 Well, i follow the link you mention and i found the answer from limetech is quite puzzling. (a) those disks in my unRaid DO support spindown because eventually those disks were spun down without problems. (b) It is just from time to time i will heard disk clicking sounds from spin up/down and every time when i heard those sounds and check syslog immediately, not surprise there are consecutive disk spin up/down entries in syslog within short period of time. © Although disk spin up/down is not an big issue however when you have operations in this short period of time and generating those clicking sounds, that is scary
July 6, 201015 yr Author Post your syslog and list the disk models that are having issues. in 1st post and it has nothing to do with "which one" but rather pretty much any of them have same issue. All my disks are either Seagate 7200 rpm 1TB or 1.5TB and some WD Green drives.
July 6, 201015 yr Post your syslog and list the disk models that are having issues. in 1st post and it has nothing to do with "which one" but rather pretty much any of them have same issue. All my disks are either Seagate 7200 rpm 1TB or 1.5TB and some WD Green drives. Attach your whole syslog I think people need to a full picture of everything.
July 6, 201015 yr Author Post your syslog and list the disk models that are having issues. in 1st post and it has nothing to do with "which one" but rather pretty much any of them have same issue. All my disks are either Seagate 7200 rpm 1TB or 1.5TB and some WD Green drives. Attach your whole syslog I think people need to a full picture of everything. It was dated back to March, the original log is gone. i went through original log and nothing unusual except those i posted at 1st post.
July 6, 201015 yr I would suggest turn off/disable all plugins/addons/packages. Reboot your system to a virgin unRAID setup. Capture the syslog. After you see the behavior, capture a new syslog. Post the syslogs for limetech to review. Email limetech directly and point to the thread with the posted syslogs.
July 6, 201015 yr Author I would suggest turn off/disable all plugins/addons/packages. Reboot your system to a virgin unRAID setup. Capture the syslog. After you see the behavior, capture a new syslog. Post the syslogs for limetech to review. Email limetech directly and point to the thread with the posted syslogs. (a) If my memory served me, i did email limetech at that time and pointed them to this thread but no response (b) yes after that incident at March i removed almost all add-on especially cache_dir © After removed add-on, now although i did not see as dramatic as in this incident in March, but from time to time i still can see from syslog there are entries of spindown for a disk in short period of time.
July 26, 201015 yr Author i thought i will put yet another log here as record, although limetech insisted this is not a bug but IMHO, i think it is. As following syslog entries shown, i was upgrading the disk12 on my unRaid to 1.5TB and data rebuild does not end until Jul 25 21:47:08 during data rebuild however disk12, 14 and 15 were spun down, disk12 is the one rebuilding that has no reason should be spun down because constant disk I/O to this disk, disk14 and 15 have 1.5TB that at that moment participating in data rebuild, also have no reason will be spun down because both of them are busy. All those 3 disk are WD, 1 EAD and 2 EAR. When this spin down took place, i heard a LOUD clicking sound coming from my unRAID apparently it is because those disks got spun down and almost immediately got spun up again. --------------------------------------------------------------------------------------------------------------------------------------------------------------------- Jul 25 14:11:33 Tower kernel: mdcmd (26): check Jul 25 14:11:33 Tower kernel: md: recovery thread woken up ... Jul 25 14:11:33 Tower kernel: md: recovery thread rebuilding disk12 ... Jul 25 14:11:33 Tower kernel: md: using 1152k window, over a total of 1465138552 blocks. Jul 25 14:19:58 Tower emhttp: resized: /mnt/disk12 Jul 25 14:19:58 Tower emhttp: shcmd (105): rm /etc/samba/smb-shares.conf >/dev/null 2>&1 Jul 25 14:19:58 Tower emhttp: _shcmd: shcmd (105): exit status: 1 Jul 25 14:19:58 Tower emhttp: shcmd (106): cp /etc/exports- /etc/exports Jul 25 14:19:58 Tower emhttp: shcmd (107): mkdir /mnt/user Jul 25 14:19:58 Tower emhttp: shcmd (108): /usr/local/sbin/shfs /mnt/user -o noatime,big_writes,allow_other,default_permissions Jul 25 14:19:59 Tower emhttp: get_config_idx: fopen /boot/config/shares/Data_backup_rsync.cfg: No such file or directory - assigning defaults Jul 25 14:19:59 Tower emhttp: shcmd (109): killall -HUP smbd Jul 25 14:19:59 Tower emhttp: shcmd (110): /etc/rc.d/rc.nfsd restart | logger Jul 25 20:14:18 Tower kernel: mdcmd (2255): spindown 2 Jul 25 20:14:18 Tower kernel: mdcmd (2256): spindown 3 Jul 25 20:14:18 Tower kernel: mdcmd (2257): spindown 5 Jul 25 20:14:18 Tower kernel: mdcmd (2258): spindown 7 Jul 25 20:14:18 Tower kernel: mdcmd (2259): spindown 13 Jul 25 21:32:15 Tower kernel: mdcmd (2773): spindown 4 Jul 25 21:32:15 Tower kernel: mdcmd (2774): spindown 6 Jul 25 21:32:16 Tower kernel: mdcmd (2775): spindown 8 Jul 25 21:32:16 Tower kernel: mdcmd (2776): spindown 9 Jul 25 21:32:16 Tower kernel: mdcmd (2777): spindown 12 Jul 25 21:32:17 Tower kernel: mdcmd (2778): spindown 14 Jul 25 21:32:17 Tower kernel: mdcmd (2779): spindown 15 Jul 25 21:47:08 Tower kernel: md: sync done. time=27327sec rate=53615K/sec Jul 25 21:47:08 Tower kernel: md: recovery thread sync completion status: 0
Archived
This topic is now archived and is closed to further replies.