On Oct 29, 2011, at 2:47 PM, J. Bruce Fields wrote: > On Sat, Oct 29, 2011 at 11:21:13AM -0700, Myklebust, Trond wrote: >>> From: J. Bruce Fields [mailto:bfields@xxxxxxxxxxxx] >>> On Sat, Oct 29, 2011 at 07:29:36PM +0200, Trond Myklebust wrote: >>>> OK. This is the first time I've seen this tcpdump. >>>> >>>> The problem seems like a split-brain issue on the server... On the >> one >>>> hand, it is happily telling us that our lease is OK when we RENEW. >>>> Then when we try to use said lease in an OPEN, it is replying with >>>> STALE_CLIENTID. >>>> >>>> IOW: This isn't a problem I can fix on the client whether or not I >> add >>>> exponential backoff. The problem needs to be addressed on the server >>>> by the Solaris folks.... >>> >>> Is there any simple thing we could do on the client to reduce the >> impact of >>> these sorts of loops? >> >> WHY? Those loops aren't supposed to happen if the server works according >> to spec. > > Yes, and it's not something I care that strongly about, really, my only > observation is that this sort of failure (an implementation bug on one > side or another resulting in a loop) seems to have been common (based on > no hard data, just my vague memories of list threads), and the results > fairly obnoxious (possibly even for unrelated hosts on the network). > So if there's some simple way to fail more gracefully it might be > helpful. For what it's worth, I agree that client implementations should attempt to behave more gracefully in the face of server problems, be they the result of bugs or the result of other issues specific to that server. Problems like this make NFSv4 as a protocol look bad. -- Chuck Lever 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
