September 11, 201015 yr The drives being spun up is likely due to your memory constraints. It's highly probable that you don't have enough memory for cache_dirs and the linux kernel to keep the file and directory entries in memory. When it runs the next cycle since the dentries are not in the memory buffers, it has to read them off the physical drives, hence causing them to spin up. With that said, it's odd that something is trying to spin down your drives when they should likely have recent usage indicators. The disk activity should reset the idle timer so it shouldn't attempt to spin them down. How can I find the info how much mem I would need for cache_dirs ? Memstatus always shows all memory allocated for buffers, right? I don't know of a way other than. Reboot. Type free to see the memory used Start cache dirs but do nothing else. Let it run for a few minutes. Type free again You can see how much memory it used for its buffers. Linux will always use as much memory as it can for buffering.
September 11, 201015 yr I modified the "maxdepth" parameter for cache_dirs to 3 (wasn't set before), which will cache the most frequently viewed files and rebooted. I usually don't notice this problem after a fresh reboot so I'll post back if I see the problem return. I'll also keep an eye on my free memory.
September 12, 201015 yr The drives being spun up is likely due to your memory constraints. It's highly probable that you don't have enough memory for cache_dirs and the linux kernel to keep the file and directory entries in memory. When it runs the next cycle since the dentries are not in the memory buffers, it has to read them off the physical drives, hence causing them to spin up. With that said, it's odd that something is trying to spin down your drives when they should likely have recent usage indicators. The disk activity should reset the idle timer so it shouldn't attempt to spin them down. How can I find the info how much mem I would need for cache_dirs ? Memstatus always shows all memory allocated for buffers, right? I don't know of a way other than. Reboot. Type free to see the memory used Start cache dirs but do nothing else. Let it run for a few minutes. Type free again You can see how much memory it used for its buffers. Linux will always use as much memory as it can for buffering. Ah, simple but good idea ... will try that next time I reboot the server. I have also already used the maxdepth parameter because I was under the impression, that it's not stopping reading from the drives and always spinng up the drives. Is there a possibility to get output in the verbose setting that's giving the user a hint, if cache_dirs is "everloaded"? I am thinking about using thumbnailer for my mediadirs - but I fear the consequences of adding an extra 16 entries per directory to be cached and maybe overloading cache_dirs memory requirements .... I only access the files from outside via SMB/usershare - so I tried the -u parameter, but wastn't sure if it caches the usershare view additionally or instead of the drive-views - so I removed it again to save memory - Joe, what would be the recommended setting in this usecase?
September 12, 201015 yr The dentries buffering is done by the Linux kernel, so as such the cache_dirs script has no means of knowing if the dentries are cached or not. Also, the /mnt/user scanning isn't needed as the dentries are pulled and created dynamically from other drives /mnt/disk#.
September 14, 201015 yr What I have done until now has not worked. I'm still getting multiple spindowns on the same disk with version 4.5.6. I cleared everything from the flash and ran a stock unraid 4.5.6 server for about a day and was still getting these multible spindowns. It seems to me that wasn't happening in the betas last winter. I've now been running 4beta11 for about a day and this problem doesn't seem to occur anymore. I'm going to keep 4beta11 running for another day and if it seems to be working I'm going to walk forward though the versions and see if I can pinpoint when this "bug" occurs.
September 22, 201015 yr I've used 4beta11 for a while with no problems. Tried 4.5 final and get a bunch of spindowns during a sync check. That just makes no sense to me: Sep 22 21:28:52 Tower kernel: mdcmd (29760): check CORRECT Sep 22 21:28:52 Tower kernel: md: recovery thread woken up ... Sep 22 21:28:52 Tower kernel: md: recovery thread checking parity... Sep 22 21:28:52 Tower kernel: md: using 1152k window, over a total of 488386552 blocks. Sep 22 21:28:55 Tower kernel: mdcmd (29763): spindown 5 Sep 22 21:28:55 Tower kernel: mdcmd (29764): spindown 6 Sep 22 21:28:56 Tower kernel: mdcmd (29765): spindown 7 Sep 22 21:28:56 Tower kernel: mdcmd (29766): spindown 8 Sep 22 21:28:56 Tower kernel: mdcmd (29767): spindown 9 Sep 22 21:28:57 Tower kernel: mdcmd (29768): spindown 10 Sep 22 21:28:58 Tower kernel: mdcmd (29769): spindown 11 Sep 22 21:28:58 Tower kernel: mdcmd (29770): spindown 12 Sep 22 21:28:59 Tower kernel: mdcmd (29771): spindown 13 Sep 22 21:28:59 Tower kernel: mdcmd (29772): spindown 14 Sep 22 21:28:59 Tower kernel: mdcmd (29773): spindown 15 Sep 22 21:29:00 Tower kernel: mdcmd (29774): spindown 16 Sep 22 21:29:13 Tower kernel: mdcmd (29776): spindown 15 Sep 22 21:29:13 Tower kernel: mdcmd (29777): spindown 16 Sep 22 21:29:16 Tower kernel: mdcmd (29778): nocheck Sep 22 21:29:18 Tower kernel: md: md_do_sync: got signal, exit... Sep 22 21:29:18 Tower kernel: md: recovery thread sync completion status: -4
September 23, 201015 yr Yeah, I'm trying 4.5.6 now and it's really bad there... I think i'm going back to 4beta11 until I get a fix or work-around for this. I wonder if there is a way to to force (or trick) unRaid to use hdparm in stead of mdcmd to spin down the disks.
September 23, 201015 yr You might be able to set unRAID to spindown NEVER and then utilize an addon script to control drive spindown. I'm not sure how it'll work, but it's worth a try.
Archived
This topic is now archived and is closed to further replies.