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