NAS

Can you describe a scenario where that would be beneficial?

Much as I am loathed to admit this the combination of "vm.vfs_cache_pressure=0", a ram based OS and no page file is probably a recipe for disaster.. just as you have seen it. unRAID in general would probably benefit from some sort of sanity cehcking RAM monitor and some more thought into OOM given all the addons that are about now and how cheap 4TB disks are. I also wonder about buying an SSD solely for page file. Conventional wisdom is SSD and page file is not a good idea but unRAID isnt a conventional setup. A 30GB+ SSD based page file would cost a few tens of bucks. It is a bit of a brute force approach but its a cheap one that will only get cheaper

700MB still sits well with me. Perhaps I am an extreme case but 8GB of RAM would still sit well with me as it represents very little percentage investment and a very real world gain. To be fair testing for a memory thing on a system that has its own memory gotchas is not ideal.. is the point I was making. Virtualsiation does a good job at making your machine not know it isnt on bare metal but under the hood quite a bit of cleverness is happening. You are probably right though it might not make a difference in this case.

The more I read about this the more I feel like Alice and the rabbit hole. Paraphrased interim reply: "There are other possibilities here in that cache_dirs is re-engineered to only cache very specific parts of the array keeping those entries in ram on purpose via some configurable method. I'm sure there's a way to do it now, but I don't know if you can give it an array of directories and/or decide the depth. " I think this is a fundamental. cache dirs or a supplemental tool should, on initial setup, help the user understand what the best setup for them is. Blindly accepting ALL or hoping that setting a max depth of 3 etc is far from ideal. A user should be able to refine it and I suspect many problem come from just this. Obviosuly presenting good info needs a whole array scan so its not a 2 second job but I think users would find it worth it. The experiments you made are very interesting. Timings aside the MB numbers of the results are comparatively small. Certainly users with large amounts of memory could accomidate a few hundred MB of reserved space. the days when 512MB was a lot of memory are gone. I am considering risking moving one of my main arrays to v6 beta just to keep the momentum up with this. I am not exicted about it but the only other option i have is vmware which I am not sure would be a good test bed for this low level stuff

very interesting ideas indeed. I think we keep this as a theoretical excercise until we can get some solid v6 64bit testing under our belt. I do think the/some of unRAID community has a different take on this to most of the Linux community as a whole. We treat inodes as expensive (to save disk spin up) whereas most treat it as cheap. Both views are correct although I suspect if someone had 24 disks in their PC they might quickly change their view. I don't want to reinvent the wheel for what could be an edge case although if we did your approach sounds eminently sensible. I have been playing with this: http://smyl.es/generating-inode-report-for-linux-ubuntu-centos-etc-with-inodes-shellbash-script/ it errors on unRAID but thats only due to lack of tmux and the results it produces are still spot on. This brings me to an idea to help reduce the problem. Regardless of what mechanism caches the inode entries a user should be able to estimate the load each included directory brings to the process in terms of inode count and ultimately RAM. I think we would have to script something as so far all the off th shelf counters dont understand the concept of inode count to xx folders deep only and memory usage needs some thought too

Obviously I agree with points 1-4 that goes without question. What I have concern about is that we cant quantify 1-4 in such a way that we can dynamically recommend defaults or provide a set of commands that definitively shows when cache_dirs is going OTT. We have always know cache_dirs was a kludge (albeit its a very skilled one) but we should be able to evolve it so that it at least doesn't create system instability or pre warn some array is getting to wide to be cached. Thinking out loud... Fundamentally the problem is a simple one. unRAID can and does create situations where one folder can be 24 disks wide. A process shouldn't have to spin up the whole or large parts of the array to get a dir listing, that is crazy. Equally a user shouldn't have to control data placement on specific disks and this goes aainst the ease of use of unRAID Even if we could come up with a way to keep the cache on a cache drive that would give people options. I would happily pay $50 for a SSD for the purpose as the real world perceived improvement for me with cache_dirs working is nothing short of amazing. I dont think the kernel allows this kind of split in page file would it i.e. a page file dedicated to inodes/dentry?

Absolutely agree its a new product with an evolution of code and internal changes. I suppose a fix is a fix though, I fully expect most people to move to v6 that can (especially if it turns out to be a free upgrade). The thing that is missing with the cache_dirs conundrum is direct quantitative results that people can post to show cache dirs is a problem and here is it doing x, y and z. Typically when there is an issue you get lame stats (like my uptime ones) or the kitchen sink (like a few posts back). Neithr of which easily shows that cache dirs is the problem (although we know it is cause if you stop it the problems go away)

V6 is 64bit compare using that.

I am sourcing some new disks to try and free up a server to test 64bit and cache dirs. Its a huge bunch of work though so I cant see it being done shy of 2 months I assume the kernel tunable you are referring to is cache pressure. if so I have never seen 0 do what it is documented to do but as you say yet again that could be 32bit and PAE. I just find it hard to believe that we cant fix it so one video stream, one preclear and once cache dirs on an i5 with 16GB of RAM cause see stuff like this: load average: 5.91, 5.53, 5.50

I just had cache_dirs go crazy. I was pre clearing a disk and then cache_dirs was causing a crazy system load. killed it via the GUI and it didnt work. Eventually i had to ps -ef | grep cache_dirs and then kil -9 the process There are some corner cases where cache_dirs can seriously cause problems. I really wish there was a cleaner way to tell the kernel "dont drop inodes, here is 4GB just for the task"

Right thats the missing fact that had me head scratching. Nice one WeeboTech. zoggy the obvious next step is for you to try the 64 bit beta and see if it can be replicated. is this viable?

In simple terms where do we believe is the ram going?

so cache_dirs took up all 4gb? is there a way to limit how much it can use? I tried running it again only on my Movies and it did the same thing. I was being a bit blind not reading the actual data 47063 47063 100% 0.41K 2477 19 19816K reiser_inode_cache Unless I fundamentally don't understand something cache_dirs is not even using 1% of available RAM.

DO we belive this is a bug (unlikely) or is cache_dirs really eating up mutiple gigs of ram. I though the last time we done the calculations for this we worked out ram should never be that high? Joe perhaps you can shed some light

yeah I reckon that is probably more common than we think it is. Unsurprising really

I have been running the new webgui since day one on 2 machines and it has never died on me. I run virtually no plugins though (cache dirs only) could this be a red herring?

No but I think the whole thing was a red herring anyway. This is new kit and the first 1.5% of checking was worryingly different to the number we expected. Once I passed that 1.5% threshold the numbers became what I would typically expect but since I had already created the thread it seemed sensible to complete the data entry.

First off extremely good work. I haven't really looked at this again since the very for page of posts so I thought I would take time to play again today. There is an elegance to your approach that is to be commended. I do however have a question/observation. The speed values reported by your tuning tool seem, for me at least, to have no to relation to the values reported by unRAID. I will keep updating this post as I eyeball values: ... 34 | 3376 | 1520 | 1520 | 106.6 MB/s 35 | 3392 | 1528 | 1528 | 106.7 MB/s 36 | 3408 | 1536 | 1536 | 106.6 MB/s Completed: 2 Hrs 8 Min 38 Sec. Best Bang for the Buck: Test 1 with a speed of 105.3 MB/s Tunable (md_num_stripes): 1408 Tunable (md_write_limit): 768 Tunable (md_sync_window): 512 These settings will consume 49MB of RAM on your hardware. unRAID v5 r3 webgui Parity-Sync: 1.2 % 48.3 MB/sec Parity-Sync: 1.4 % 34.7 MB/sec Parity-Sync: 1.6 % 112.4 MB/sec Parity-Sync: 2.5% 112.1 MB/sec Parity-Sync: 3.0% 111.9 MB/sec Parity-Sync: 23.1% 93.4 MB/sec Parity-Sync: 31.1% 82.9 MB/sec Parity-Sync: 31.1% 74.3 MB/sec Parity-Sync: 42.7% 67.1 MB/sec Parity-Sync: 48.7% 54.3 MB/sec Parity-Sync: 57.7% 99.4 MB/sec Parity-Sync: 78.8% 95.7 MB/sec update: it just sped up, very odd indeed. I can reproduce this by cancelling and starting again up2date2: number > 50% are less meaningul as i have a mix of 2,3 and 4Tb disks however for completeness i will keep posting

hehe.. just for giggles i ran that command on /mnt/user/ 161915 Music 96022 Personal 10391 TV 7107 Movies 2017 Media What i fond was random stuff that had been dumped that came from windows had zillions of small files. Added up all thee backups and caches had hundreds of thousands of files

Agree - I guess Tom is still working out his github workflow. The problem he'll be facing is that you don't want to commit untested changes to the official repo (from a support point of view). This is really unfortunate. It really goes against how git is designed to be used. * Commit often with small, atomic commits * Tag stable releases * Master is unstable (OR master is production ready and another branch, like dev, is the primary) * On Sausage Making http://sethrobertson.github.io/GitBestPractices/#sausage I have not read that whole link yet but it looks excellent. I particularly like the sausage making analogy. To no one in particular... lets not let this thread get out of hand. As we all know Tom is dealing with real life things this now that make all this stuff nonsense. Until then the one thing I would recommend is that people realise that Limetech pushed this code to github for more than just visibility. As they say in all the worst help channels... patches welcome. But seriously the way to make this work is to push back changes.

I think people are used to seeing regular activity on github as opposed to the "checkout, do it all end to end offline and then put it all back in as one monster change" method of working. It is not for me to say how best to work but lots of incremental changes tend to be better accepted by everyone and for encouraging code submissions. They also have the side benefit of allowing earlier testing, faster bug finding and showing progress is happening.

unsupported 3rd party control panel installing unsuported 3rd party addons with almost no explanation on the logic of how it works. the effort is to be highly commended but it simply scares me people are prepared to randomly install all this stuff anyway this is completely unrelated to this thread. back OT please

In simple terms a fork allows someone to take something, fix it, let people test it and crucially push the fixes back upstream in the form of a pull request. This means fixes can be reviewed and accepted upstream as small lumps of code which developers can then deal with and revert later if needed. This is the proper way to group work in git. Not fork as in "fork and create your own project forever"... different thing. This is also better than branches at the host project as those get complicated fast if you have a bunch of devs.

No dont do that let people fork and people can test forks before commiting back upstream

webGUI. There will be only one as the song goes Certainly as the vast majority of unraid users dont spend much time at the command line.