Comment # 13 on bug 908706 from Mark Draheim

Tried again: kernel 3.19.3, cachefilesd on nfs, see the last two attachments
for details. The debug parameter on cachefiles does not provide any more info.

Setup: 

* new export from the server, new nfs mount on the client
* placed gcc source on the share
* put some load on the system: find . -type f -name '*.c' -exec sed -i -e
's/$/bar/g' \{\} \; && find . -type f -name '*.h' -exec sed -i -e 's/$/bar/g'
\{\} \;

It will eventually oops out. The error is the same as with kernel 3.16. It only
seems to happen under rw load. That is why my initial report blamed KDE but it
probably was only akonadi/baloo doing heavy rw which triggered the oops.

The nfs server is a fairly low spec machine. I wonder if I should try again on
a more powerful computer or maybe the nfs export conf is odd. That too is in
the attachments.

What really puzzles me is that du always reports 0 on fscache, though that
apparently does cache something. The "Lookup failed -1" message is always there
on the first run, ie nothing in the cache yet(?). On the second run the lookup
fail message show less often.