Subject: [nfsv4] Fix LAYOUTCOMMIT error return

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Fri, 21 May 2010 09:53:07 -0400

Hello

Unless I'm missing something, NFS4ERR_WRONG_CRED should be removed as
a possible error for
LAYOUTCOMMIT because LAYTOUTCOMMIT does not manipulate state.

5.1.6.4. NFS4ERR_WRONG_CRED (Error Code 10082)

   An operation that manipulates state was attempted by a principal that
   was not allowed to modify that piece of state.

-->Andy

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 27 May 2010 12:36:59 -0700

I believe the rationale is if credential X creates the layout stateid (e.g. via LAYOUTGET), then 
credential Y can't be allowed to commit the layout, if Y has the appropriate write
permissions to the file.

The state of the layout does change after LAYOUTCOMMIT, at least for some
layout types.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of William A. (Andy) Adamson
> Sent: Friday, May 21, 2010 6:53 AM
> To: NFSv4
> Subject: [nfsv4] Fix LAYOUTCOMMIT error return
> 
> Hello
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 27 May 2010 16:11:26 -0400

> credential Y can't be allowed to commit the layout, if Y has the appropriate write

Hmm... What if credential X gets its write permissions revoked? Would
that require you to resend the entire set of writes?

> The state of the layout does change after LAYOUTCOMMIT, at least for some

The state of the file certainly does change (which is why you need write
permissions), but what changes in the layout state?

Cheers
  Trond

---

From: "William A. (Andy) Adamson" <[email-masked]>
Date: Thu, 27 May 2010 16:55:57 -0400

>> credential Y can't be allowed to commit the layout, if Y has the appropriate write

So the credential is attached to the layout stateid which makes this
similar to EXCHGID4_FLAG_BIND_PRINC_STATEID for READs and WRITEs,
except this is for LAYOUTGET/COMMIT/RETURN, and is required only for
some layout types (not the file layout)

> that require you to resend the entire set of writes?

I suspect that if the layout stateid is still valid, the LAYOUTCOMMIT
will succeed even though credential X no longer has write permission,
because this is permission to change the layout state granted when
credential X did have write permission.

> permissions), but what changes in the layout state?

For the block layout type, the state of an extent (in the layout) that
was written to changes and the LAYOUTCOMMIT informs the server that it
is so.

-->Andy

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 27 May 2010 17:12:38 -0400

> credential X did have write permission.

That would be a change w.r.t. the general NFS policy of checking
permissions on each operation. New WRITE calls are, for example,
expected to fail, despite the OPEN stateid still being valid.

> was written to changes and the LAYOUTCOMMIT informs the server that it

The _layout_ doesn't change. The client retains the same ability to read
or write to the same extents.

To my mind your 'extent state' in the above context is file metadata. It
may be described in the layout, but it doesn't pertain to your ability
to read/write to data servers.