> Umm... If the client is sending delegreturn, then why not destroy the > delegation? ObDisclaimer: My "internal" version of this patch does just that. If the DELEGRETURN is the first time that the client hears of the revocation, I'm guessing that there isn't anything that can be done to rewind time and do anything differently. But as Bruce points out, it seems like there are other places where NFS4ERR_DELEG_REVOKED should be being returned. > What is the point of forcing the client to send > FREE_STATEID, when it is telling you that it is no longer caching any > locks or associated state and is no longer interested in keeping the > delegation? But - I keep re-reading RFC5661, and I can't figure out how this is what was intended. It seems like the "correct" thing to do is inform the client (via probably too many different methods) that the/a delegation is revoked and let it acknowledge via FREE_STATEID. The allowed error returns in 15.2 seem to confirm this view. 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
