Jonathan Nieder <jrnieder@gmail.com> 2012-07-20 11:25:
merge 682116 682007 quit Hi, Ben Hutchings <ben@decadent.org.uk> 2012-07-19 13:32:On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:We don't support proprietary stuff. Please remove and try again.To be clear, Bastian is referring to the proprietary kernel module (nvidia).I think this stance is too aggressive. Testing without the modules we do not support can certainly help, but in cases like this where the proprietary module is not likely to be related, I'd rather hear about problems earlier than have submitters wait until they have time to reproduce without. Luckily this has been reproduced without the nvidia module, so merging. Rhaoul writes: This is reproducable using "grep -r abc *" inside a directory with 9541 files (no sym- or hardlinks, no block or character special files) in 1524 directories (PHP MODX installation)
I downloaded the couple of files from that site [1] and unzipped them to hopefully create a similar test setup. I had to make two copies of it to get that many files/dirs.
Right now I'm running this to see what happens:
# for i in {1..100}; do grep -r abc /cae/apps/data/testapp-1/tmp* > /dev/null; done
So far nothing much, but I just started.
Some other points for comparison:- does the cache need to be fresh? I have a cron job that does this from time to time (about once a month with some random splay between machines) on these machines anyways (basically stop cachefilesd && rm -rf the_cache_dir_contents && start cachefilesd)
- anything else in particular about the test I should look for?I've also noticed that I can usually get cachefilesd to spin to 100% cpu if I do something like this:
# grep pattern /home/logs/some_multi_gb_large_readonly_logfileI recall seeing patches for large file support, but wasn't sure on their status. Anyways, that's digressing, so I'll leave that as a separate item for later.
Thanks, Brian [1] http://modx.com/download/
Attachment:
signature.asc
Description: Digital signature