On Tue, Mar 29 2016, Tom Talpey wrote: > On 3/28/2016 12:04 PM, Frank Filz wrote: >>> >>> Forcing the xid to change on every retransmit (for NLM) would ensure that >>> we only accept the last reply, which I think is safe. >> >> That sounds like a good solution to me. Since the requests are non-blocking, >> each request should be considered separate from the others. > > I totally disagree. To issue a new XID contradicts the entire notion of > "retransmit". It will badly break any hope of idempotency. > > To me, there are two issues here: > 1) The client should not be retransmitting on an unbroken connection. Do you mean by that that it shouldn't retransmit, or that it should break the connection? The first would help in my case, but is a fairly substantial change to the protocol. I'm not at all certain the second would help. > 2) The server should have a reply cache. As I said, I think a reply cache would make problems less common, but unless it is of unlimited size, it cannot guarantee anything. > > If both of those were true, this problem would not occur. > > That said, if client B were to *drop the connection* and then *reissue* > the lock with a new XID, there would be a chance of things working > as desired. That is consistent with what I was proposing. > > But this would still leave many existing NLM issues on the table. It's > a pipe dream that NLM (and NSM) will truly support correct locking > semantics in the face of transient errors. While perfection may well be unattainable, that shouldn't stop us from fixing things which can be fixed. Thanks, NeilBrown > > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@xxxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html
Attachment:
signature.asc
Description: PGP signature
