Have you tried using snoop on your Solaris clients? The output (run with no options) includes getattr calls with a filehandle number, and "LOOKUP3" calls sometimes include a FH# and a filename. It seems that with the right options, the data you want is available.
You might try capturing packets for a few seconds into a file, and then using various options until you come across the one that works for you.
Re:
Date: Thu, 26 Aug 2004 14:08:00 -0400 From: "John Stoffel" stoffel@lucent.com To: Jerry juanino@yahoo.com Cc: John Stoffel stoffel@lucent.com, "'NetApps list server'" toasters@mathworks.com Subject: Re: Tracing NFS getattr() calls to a file
Jerry> I saw some scenarios where using mixed speeds caused problems Jerry> unless I switched to tcp. The filer was attempting to send Jerry> stuff fast than the client could accept (gig to 100mb). This Jerry> would cause the client to re-request packets, and would spiral Jerry> down into horrible performance on the client. I never saw the Jerry> filer cpu rise, but I suppose it could be the same. Do you see Jerry> poor performance as well, or just a spin up in cpu?
Nope, no performance problems on the clients from what I see. They're builds just crank along. They *seem* to be doing a bunch of parallel builds. If you're familiar with ClearCase, it lets you specify a bunch of hosts to do parallel builds on, so you can farm out a build job across multiple hosts.
I think once I can figure out which file(s) they're doing the getattr() calls against, I can then chase down the problematic change in their build setup or whatever.
Thanks for the suggestions, John John Stoffel - Senior Unix Systems Administrator - Lucent Technologies stoffel@lucent.com - http://www.lucent.com - 978-952-7548