Subject: [nfsv4] RFC3530bis-28: Delegations

From: Marcel Telka <[email-masked]>
Date: Wed, 23 Oct 2013 21:55:07 +0200

Hi all,

While reading about delegations in the RFC3530bis-28 few questions popped-up.

The chapter 10.4.4. states that a delegation should be recalled in a case there
is REMOVE or RENAME request for the file. Should the delegation be recalled
_before_ the actual REMOVE/RENAME is performed, or could it be done _after_ the
the file is removed/renamed?

The only difference between _before_ and _after_ seems to be that the original
name of the file might be no longer available. Must the filename be available
during the delegation recall/return? Is there some other reason than
CLAIM_DELEGATE_CUR (see below)?

When a delegation is returned the client is suggested to use OPEN with
CLAIM_DELEGATE_CUR. There are three arguments identifying the file we are
trying to open:

  directory (CURRENT_FH)
  delegate_stateid
  file (filename)

To uniquely and sufficiently identify the file either the delegate_stateid or
both directory/filename seems enough. What should the NFS server do when the
combination of these three agruments does not point to one file?

Example:

delegate_stateid is pointing to file /dir1/file1, but the current filehandle
(directory) points to /dir2 and filename is file2 (which might either exist or
does not exist).

What should be the conformant NFS server behavior?
  1) Open the file based on delegate_stateid, or
  2) (Try to) Open the file based on directory/filename, or
  3) Fail (because delegate_stateid does not match directory/file), or
  4) Either (and all of) 1, 2, 3 is conformant.

Thank you.

-- 
+-------------------------------------------+
| Marcel Telka   e-mail:   [email-masked]  |
|                homepage: http://telka.sk/ |
|                jabber:   [email-masked] |
+-------------------------------------------+

---

From: "Noveck, David" <[email-masked]>
Date: Wed, 23 Oct 2013 17:03:42 -0400

Before.  If it were "after", the obvious next question is "how long after?" and nobody wanted to go there.

The big reason that you want the delegation return completed is that the handling of RENAME and REMOVE might, depending on the file system in question, depend on whether/how the file is opened, and when delegations are outstanding, the server doesn't know that for sure.

RFC3530bis isn't very explicit about this, but note that RENAME and REMOVE can return NFS4ERR_GRACE.  The situation is similar in that the server doesn't know if a file is really open, when there might be an open-reclaim done.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marcel Telka
Sent: Wednesday, October 23, 2013 3:55 PM
To: [email-masked]
Subject: [nfsv4] RFC3530bis-28: Delegations

Hi all,

The chapter 10.4.4. states that a delegation should be recalled in a case there is REMOVE or RENAME request for the file. Should the delegation be recalled _before_ the actual REMOVE/RENAME is performed, or could it be done _after_ the the file is removed/renamed?

The only difference between _before_ and _after_ seems to be that the original name of the file might be no longer available. Must the filename be available during the delegation recall/return? Is there some other reason than CLAIM_DELEGATE_CUR (see below)?

When a delegation is returned the client is suggested to use OPEN with CLAIM_DELEGATE_CUR. There are three arguments identifying the file we are trying to open:

  directory (CURRENT_FH)

  delegate_stateid

  file (filename)

To uniquely and sufficiently identify the file either the delegate_stateid or both directory/filename seems enough. What should the NFS server do when the combination of these three agruments does not point to one file?

Example:

(directory) points to /dir2 and filename is file2 (which might either exist or does not exist).

Thank you.

--

| Marcel Telka   e-mail:   [email-masked]<mailto:[email-masked]>  |

|                jabber:   [email-masked]<mailto:[email-masked]> |

_______________________________________________

nfsv4 mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Marcel Telka <[email-masked]>
Date: Thu, 24 Oct 2013 00:02:15 +0200

On Wed, Oct 23, 2013 at 05:03:42PM -0400, Noveck, David wrote:
> The big reason that you want the delegation return completed is that the
> handling of RENAME and REMOVE might, depending on the file system in
> question, depend on whether/how the file is opened, and when delegations are
> outstanding, the server doesn't know that for sure.

What in a case the rename/remove request comes locally at the server (i.e. not
via NFS)?  Provided the local rename/remove cannot fail depending on
whether/how the file is opened.  Could "after" cause any issue for NFS clients
(or the NFS server) in this scenario?

To rephrase the question: While a delegation is granted (and not recalled yet),
would the NFS server violate the RFC in a case the filename disappear from the
directory?

Thanks.

---

From: Marcel Telka <[email-masked]>
Date: Thu, 24 Oct 2013 00:06:10 +0200

> and nobody wanted to go there.

Shouldn't we note this in the RFC?

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 25 Oct 2013 14:03:46 -0400

> Shouldn't we note this in the RFC?

http://tools.ietf.org/html/draft-ietf-nfsv4-rfc3530bis-28#section-10.2

	"The conflicting request will not be acted on until the recall
	is complete.  The recall is considered complete when the client
	returns the delegation or the server times out its wait for the
	delegation to be returned and revokes the delegation as a result
	of the timeout.  In the interim, the server will either delay
	responding to conflicting requests or respond to them with
	NFS4ERR_DELAY."

--b.

---

From: Marcel Telka <[email-masked]>
Date: Tue, 29 Oct 2013 08:39:08 +0100

> 	responding to conflicting requests or respond to them with

Thank you. This addressed my concern.

---

From: Marcel Telka <[email-masked]>
Date: Tue, 29 Oct 2013 14:05:45 +0100

Do you have any idea/suggestion about this?

Thanks.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 29 Oct 2013 11:34:42 -0400

> >   4) Either (and all of) 1, 2, 3 is conformant.

The Linux server returns NFS4ERR_BAD_STATEID in this case, which is what
is suggested e.g. on page 164 of rfc 5661:

	"If the selected table entry does not match the current
	filehandle, return NFS4ERR_BAD_STATEID."

--b.