Re: NFS4ERR_STALE_CLIENTID loop

[David Flynn <davidf@rd.bbc.co.uk>]

* Myklebust, Trond (Trond.Myklebust@netapp.com) wrote:
> > -----Original Message-----
> > From: Chuck Lever [mailto:chuck.lever@oracle.com]
> > On Oct 29, 2011, at 2:47 PM, J. Bruce Fields wrote:
> > > 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...

Indeed, it is a quite the dilemma.

I agree that giving and guaranteeing unattended data loss is bad (data
loss at the behest of an operator is ok, afterall they can always fence
a broken machine).

Looking at some of the logs again, even going back to the very original
case, it appears to be about 600us between retries (RTT=400us).  Is
there any way to make that less aggressive?, eg 1s? -- that'd reduce the
impact by three orders of magnitude.  What would be the down-side?  How
often do you expect to get a BAD_STATEID error?

..david