Re: nfs client performance while server is down

[Chuck Lever <chuck.lever@oracle.com>]

On 01/26/2010 06:21 PM, J. Bruce Fields wrote:
> On Mon, Jan 25, 2010 at 02:08:47PM -0500, Chuck Lever wrote:
>> On Jan 25, 2010, at 2:02 PM, Whoop Whouzer wrote:
>>> Ok, I did that, after shutting down the server and enabling debug
>>> trace I tried to open the home folder of the current account (totally
>>> unrelated to the nfsshare), it wouldn't open at all, I got no nautilus
>>> at all. During the time my cursor was in busy mode I got the following
>>> messages in kern.log (for ubuntu 10.04 client):
>>> Jan 25 19:30:13 whoop-desktop kernel: [  160.719262] NFS call  fsstat
>>> Jan 25 19:30:37 whoop-desktop kernel: [  184.458611] NFS:
>>> permission(0:16/74386), mask=0x10, res=0
>>> Jan 25 19:30:37 whoop-desktop kernel: [  184.458647] NFS call  access
>>> Jan 25 19:30:43 whoop-desktop kernel: [  190.721086] nfs: server
>>> 192.168.1.130 not responding, timed out
>>> Jan 25 19:30:43 whoop-desktop kernel: [  190.721113] NFS reply statfs:
>>> -5
>>> Jan 25 19:30:43 whoop-desktop kernel: [  190.721116] nfs_statfs:
>>> statfs error = 5
> ...
>> This verifies that your client is attempting to access the NFS server,
>> but doesn't tell us which file it's attempting to access.  Essentially
>> the EIO means "failed to connect".
>
> I wonder if nautilus (or some library it uses) likes to regularly
> "statfs" all the filesystems it knows about?

The NFS client seems to like to send these periodically, but I've never 
looked into why.  It's probably triggered by some cache timeout, and 
gathers recent server file system information.

The ACCESS command is for a particular file, however.  That's probably 
where we will get the most interesting and specific information.  A 
network trace would capture the FH in the ACCESS request.  When the 
server is up, you could match that FH to other requests where the actual 
pathname of the file is known.

Simply run wireshark on your client, and it should automatically sniff 
the FH information.  Wireshark would need to be running while the server 
is up and continue running after the server is taken down.

-- 
chuck[dot]lever[at]oracle[dot]com