> -----Original Message----- > From: Chuck Lever [mailto:chuck.lever@xxxxxxxxxx] > Sent: Saturday, October 29, 2011 8:51 PM > To: J. Bruce Fields > Cc: Myklebust, Trond; David Flynn; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: NFS4ERR_STALE_CLIENTID loop > > > 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. I can't see what a client can do in this situation except possibly just give up after a while and throw a SERVER_BROKEN error (which means data loss). That still won't make NFSv4 look good... 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
