Re: nfs client performance while server is down

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Jan 27, 2010 at 01:40:07AM +0100, Whoop Whouzer wrote:
> Could be, although not very likely as it was also reported happening
> with thunar (although I have not tested this myself).
> But I am also experiencing similar problems with other applications
> even gnome-terminal (basically all applications requiring (local) disk
> access).
> So this would led me to think it is some sub-process, that is used by
> all application requiring disk access, that is to blame...

You could patch the kernel to add printk()'s in statfs showing who is
calling it (and with what path).

But probably there's some tracing infrastructure that would make this
possible without patching.

--b.

> 
> On Wed, Jan 27, 2010 at 12:21 AM, J. Bruce Fields <bfields@fieldses.org> 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?
> >
> > --b.
> >