NAS

Easier to comment inline It sounds as if you need to either: A. install more RAM [NAS] 4GB is alot already surely B. limit the directory depth cached. [NAS] I dont do this currently C. limit (include or exclude) specific user-shares to limit the directories cached. [NAS] I make heavy use of this. Only TV and movies are included D. use the min-time and max-time parameters to set the min and max time between"find" commands in cache_dirs. [NAS] Need to ponder this one E. modify cache_dirs as it suits YOUR needs. (It is just a shell script after all) [NAS] Have already F. stop using cache dirs. Apparently, your limited memory and high number if directory nodes COMBINED with other use of memory on your server cause the cache_dir "find"command to take too long and end up causing the directory entries in memory to be freed to be re-used by other processes accessing the disks. The last one I dont get. If i do nothing on the server for 12 hours AFTER i stop moving files around cache_dirs still is trying to keep get a handle on indexing. There are no addons of any sort other than cache_dirs and SNAP. Its as if the kernel is not dropping file caches in favour of inode caches. There should be not difference between unRAID after several hours of no access and a clean boot in terms of cache_dirs

Heres an interesting one. I have noticed this before on 4.7. I have a box that I have moved a load of files about from disk share to disk share using mc. The idea was/is to merge common file that got split up due to highwater e.g. /TV/Show/S01 ended up on several disks. However after a certain (and unknown) point of doing this cache_dirs never seems to let disks spin down. Its as if there's never enough memory to fully hold this inode data and the result is the disks never spin down again. If I spin down the disks manually the disks spin up again. If I kill cache_dirs the disks will spin down naturally. If it reboot the box cache_dirs does it jobs and disks spin down normally. This isnt ideal as at a certain point cache_dirs moves from being excellent to a complete hindrance. I will keep this box up for a few hours if your about and want some data from it. After that i need to spin down cause its quite warm here today. Cheers

Thats the main reason i didnt look at cache_dirs sooner. Here the thing though I could watch via lsof and grep cache_dirs walk the directory when the server had been sitting for several hours doing nothing. Now that I have removed the XBMC artwork cache from cache_dirs drives sleep as expected. I dont think it is a math problem but rather a cache pressure problem. Currently I have: vm.vfs_cache_pressure = 5 I know the kernel documentation states "When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes" but this in my experience is not correct with a zero value being no different to a low value.

Just a word of warning. cache_dirs started becoming the daemon that actually spun up all my disks. In the end the core issue was obvious but for a while it had me scratching my head. I placed my XBMC library artwork folders on unRAID. XBMC creates huge amounts of art files so essentially even with 4GB or ram and normal usage expesive cache data i.e. my media colection was being pushed out by non expensive data i.e. my artwork cache. Approcimately XBMC creates two jpg art files per movie, one per tv show and 30+ for actor thumbs. Realsiitically your looking at 20-30 image files per video file. I havent confirmed this completely but i have made the changes and should be able to confirm soon. I so wish there was a better way to do this as going beyond 4GB for ls data seems silly and has obvious PAE implications.

Joe I started reading about kernel tubales again. And yet again if stumbled on http://kerneltrap.org/node/4462 Perhaps there are a couple of more tunables that could be of use in unRAID very special uage case: Specifically vm_vfs_scan_ratio and vm_cache_scan_ratio may be useful. I am suffering from lack of documentation. It seems when you get to this level you are expected to be able to speak in kernel code.

2GB i believe. I havent really looked at ram usage but from a user POV everything seems to just work

Way ahead of you. Purely based on casual observations setting 0 REALLY makes a difference for me. Wouldn't it be nice if the kernel would allow you to reserve a portion of memory dedicated to this cache then swap based on cache pressure and all the other magic if more than this was needed. Oh to know a kernel developer/

That exlains alot. cat /proc/sys/vm/vfs_cache_pressure 10 is overriding my value of 0 in in go script. I was scratching my head why disk were spinning up more. Now we have an answer.

I am certain this will be of help to alot of users. If you can find the time could you add a wiki page for this and edit it there. In the long term thats a far better place for these things. Kudos p.s. if you get stuck with formatting etc just PM me and I will do it for you

Theres also the striping-all-or-nothing approach of RAID 5 to take into account. By definition unRAID is not vulnerable to the catastrophic failures that can happen with a striped RAID.

Not read it yet but here it is: http://www.tomshardware.com/news/RAID-5-Doomed-2009,6525.html Similar to a post made previously.