* Myklebust, Trond (Trond.Myklebust@xxxxxxxxxx) wrote: > > -----Original Message----- > > From: Chuck Lever [mailto:chuck.lever@xxxxxxxxxx] > > 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 -- 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
