Hrm, for me the problem seems (so far) to have gone away when I use "udp" instead of "tcp" with the nfs mount. (Maybe it was related to the tcp over tcp bad idea, http://sites.inka.de/bigred/devel/tcp-tcp.html ) And, now that I think of it, I was using "udp" originally, and only recently was forced to use "tcp" due to some bizarre error, which seems to have resolved itself. On Mon, 19 Apr 2010 10:34:12 -0400, Michael O'Donnell wrote: > Well, it's encouraging to finally get a response and even more so that > you may be seeing the same kinds of failures. I will post logging > output from /var/log/messages from the client and server machines > while the failures are occurring and maybe we can compare notes? > > > Dennis Nezic wrote: > > Well I for one am convinced there is a bug either in the linux > > kernel, or somewhere. I have a similar problem (I posted about it > > here on March 18 2010), where NFS activity very frequently hangs > > for several minutes, for no good reason. (Changing the nfs mount > > option to "hard" should get rid of the I/O Errors, but it's still > > incredibly frustrating/annoying > > -- it will simply retry after precious minutes have been wasted, > > instead of failing :b). My problems began ONLY after I upgraded my > > server's kernel. When did yours begin? > > > > I have noticed that when a client hangs, other clients still work -- > > ie. the nfs server is still (sortof) working -- so I imagine there > > is something wrong with the client too? > > > -- > 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 > -- 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
