On Tue, Oct 13, 2015 at 3:46 PM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > On Tue, Oct 13, 2015 at 1:58 PM, Andrew W Elble <aweits@xxxxxxx> wrote: >> >> Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> writes: >> >> >> > OK. So what are the symptoms? I'm having trouble seeing how a race can >> >> > happen, given a correctly coded server. >> >> >> >> Here's what the server sees: >> >> open (foobar) replies back with a delegation >> >> various operations including a close() >> >> some time goes by... >> >> open (foobar) replies back with the same delegation >> > >> > Why? Olga, we already had this discussion. That sort of server >> > behaviour is never going to work without races and is the root cause >> > of your problem. We simply won't ever support servers that do this. >> >> Trond, >> >> Specifically, what would the correct behavior be here? > > The server should honour the open without repeating the delegation. > > The client already knows about the delegation due to the first open, > so there is no value whatsoever in repeating it. In addition, as you > see from Olga's example, it causes races with the return of that > delegation. Trond thank you for the explanations. While I haven't hit the last case of the race I would still like to bring up that we've seen a case where ACCESS is sent and then DELEGRETURN and then delegation stateid is used by the IO. Perhaps the commit 5e99b532bb95 helps in that case. But if not, then this case of the race can't be handled by the server. -- 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
