On Thu, Dec 03, 2015 at 05:08:50PM -0500, J. Bruce Fields wrote: > OK, so if I understand right, the current code is letting the rpc state > machine drive the whole thing, and your proposal is that the rpc task > lasts until the client either responds NFS4ERR_NOMATCHING_LAYOUT or we > just run out of time. (NOMATCHING_LAYOUT being the one response that > isn't either "try again" or "OK I'll get to it soon"). Yes (except fatal errors would end the rpc state machine). > I understand why that would work, and that handling anything other than > the NOMATCHING_LAYOUT case is a lower priority for now, but this > approach worries me. > > Is there a reason we can't do as in the delegation case, and track the > revocation timeout separately from the callback rpc? There is no reason not to do it, except for the significant effort to implement it a well as a synthetic test case to actually reproduce the behavior we want to handle. -- 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
