On Sat, 2010-10-30 at 17:29 -0400, Brian J. Murrell wrote: > On Sat, 2010-10-30 at 14:19 -0400, Trond Myklebust wrote: > > > > BTW: Do you have the following patches applied? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=b0ed9dbc24f1fd912b2dd08b995153cafc1d5b1c > > and > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git&a=commitdiff&h=ae1007d37e00144b72906a4bdc47d517ae91bcc1 > > These patches both deal with recovery issues, which you mentioned seems > to be the state the previously posted stack traces where in also. > > Since the server has not been rebooted or even had its export list > reread/reexported, I wonder why recovery would have been triggered, to > cause this client problem. > > Does recovery actually get invoked on the client for events other than > an outright restart of NFS on the server? NFS on the server here should > have been entirely stable over the period of time in which this client > went bad. There are 2 cases which can trigger recovery: server reboot, and network partition (i.e. a networking fault that causes the client to be unable to contact the server in time in order to renew its lease). If none of the above apply, then we need to look at whether it is the client or the server that is screwed up. Trond -- 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
