We're running nfs over a cluster of isilons and are intermittently experiencing quite a lag when creating a dir on one machine and reading on another (of about 30s).
This only seems to happen when the network is quite busy, but it has been suggested that running 'ls' on the parent directory before trying to read the new directory will force the NFS to re-cache.
Does that sound right?
Sounds like you need to tune the acdirmin/acdirmax mount options on your clients to change the upper and lower bounds on cache age of directory info. That 30 seconds corresponds with the default acdirmin of 30 seconds, which means information has to be in the cache at least 30 seconds before the client will consider going out and refreshing it.
See if tuning acdirmin down to 15 or 10 seconds helps out.
Also, the reason the 'ls' might be helping out is that it's causing a stat() to occur on "." which could potentially be invalidating the cache for that dentry. I recall us having to modify some of our tools to stat() a file or directory before open() in order to validate that the item was there for some of our NFS stuff.
So this is other clients noticing that the file has file has been created ? ( or does it include changes in how much data the files contain ).
Are the operations all in a single directory as isilons have issues with metadata performance in a single directory.
Are you sure its not the server writing the file which is doing the cachine, if you log into the isilon and watch the directory from the "appliance" do you see the files appearing on the server at the same time as the client says it has writtern it.
Out of curiosity are the two machines mounting the same isilon brick ( while it is not supposed to matter it would be interesting ).
What mount options do you have ? ( Does nfs v2 make any difference ( more a curiosity , it does not have readir+ ))
