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
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
