Subject: [nfsv4] error on OPEN(CLAIM_DELEGATE_CUR)

From: Fred Isaman <[email-masked]>
Date: Thu, 31 Jul 2014 10:03:01 -0400

This popped up on the linux client, but is a general protocol question...

What is the client supposed to do when it receives an error (in this case
ADMIN_REVOKED or BAD_STATEID) to an OPEN(CLAIM_DELEGATE_CUR) sent during
delegation return?

One option is to try to OPEN(CLAIM_NULL) the file and dump local data, but
that (and pretty much every other option I've come up with) seems a recipe
for data corruption.

Fred

---

From: Malahal Naineni <[email-masked]>
Date: Thu, 31 Jul 2014 10:13:10 -0500

>    that (and pretty much every other option I've come up with) seems a recipe

If it is a read delegation, I imagine you can do OPEN(CLAIM_NULL) and
may purge cache! If it is a write delegation with outstanding data, the
client should let the applications know the error (in response to
sync/close/write etc.).

Regards, Malahal.

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 31 Jul 2014 15:30:20 +0000

On Jul 31, 2014, at 10:03 AM, Fred Isaman <[email-masked]> wrote:

> What is the client supposed to do when it receives an error (in this case ADMIN_REVOKED or BAD_STATEID) to an OPEN(CLAIM_DELEGATE_CUR) sent during delegation return?

So this means that the server has thrown away or lost the delegation stateid that the client is attempting to return. If it was a WRITE delegation, then the client could have been doing local LOCKs OPENs and WRITEs independent of the server, and without the server enforcing the delegation, data corruption via another client is quite possible. I see no good way out of this situation for a WRITE delegation.

—>Andy

> 
> One option is to try to OPEN(CLAIM_NULL) the file and dump local data, but that (and pretty much every other option I've come up with) seems a recipe for data corruption.
> 
> Fred
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4