On Wed, Oct 14, 2015 at 10:58 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > 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. That's a different bug, and is indeed a client issue. It should be fixed by commit 24311f884189 + 5e99b532bb95. Please let me know if that is not the case. -- 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
