NFS latency when Solaris 10 client mounts Linux NFS server(EMC NAS)

Question

Hello,
One of our developers discovered a problem that for simplicity we call "latency". We have several 5.10 clients that we see the exact same symptoms on when NFS mounting our Celerra. The NAS is running a Linux variant "2.4.9-34.5406.EMC", but before you all jump on the "it's EMC's problem" bandwagon, let me explain. We set up an automated process (Perl) that watches an exported folder for the appearance of a request file (rand.req). When the request file comes in we rename the request file to (rand.sav) and then return a "report" named (rand.res). Very elegent I thought, and it runs at near lightspeed when only Linux NFS clients mount the share and create, monitor, delete, etc any files. In fact there is zero recorded latency from the time the report file appears and when the client detects it. But for all our Solaris 10 clients, they create the request file just fine, and the Perl process running on the Linux box sees the file instantaneously and returns the report, but it takes the Solaris client anywhere from 5 to up to 50 seconds before it see's any change in status for any files the Linux box manipulates. I've tried every possible combination of mount -o options there are including noac, rsize and wsize variants, vers=2, proto=udp, actimeo=0, etc, etc, etc. Nothing seems to be the magic bullet. nfsstat -c shows nothing out of the ordinary. There are no retransmits or dropepd packets anywhere in between, no firewall loads, no connectivity delays whatsoever. I'm completely out of ideas. Any ideas or clues would be greatly appreciated!
thanks
Dave

Answer 1

No specific recommendations. But maybe you can watch the cable and get more information.
Set up a case where the file has been created, then have the client check and snoop the cable at the same time. Does the client actually issue a directory check (or is it just displaying cached information)? Does the response contain the new file?
Something to test anyway...
Darren