> Yeah, there will always be some potential for a CB_RECALL/DELEGRETURN > race since the former is driven by the server and the latter by the > client. I believe there are some client differences to account for as well. i.e. when does the client "unhash" the delegation? Before the DELEGRETURN is sent, or after the response comes back? > What error are you usually getting back from the client when you see > this happen? NFS4ERR_BAD_STATEID? If so, then maybe we should confine > this check to that error case? Usually EBADHANDLE. I actually had a version of this patch where it was confined to those cases. My rationale in changing it was that continuing to solicit the return of the delegation when we have it is pointless. i.e. RFC5661 20.2.4: "...The recall is not complete until the delegation is returned using a DELEGRETURN operation." Thanks, Andy -- Andrew W. Elble aweits@xxxxxxxxxxxxxxxxxx Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912 -- 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
