Subject: [nfsv4] NFSv4.2 inter-server question

From: Olga Kornievskaia <[email-masked]>
Date: Tue, 24 Feb 2015 16:12:33 -0500

Hi Tom,

Minor typos:
1. I noticed that section 4.2.2, 3rd paragraph, has COPY_NOTICE instead of
COPY_NOTIFY.
2. In 15.3.3, there is a mention of COPY_REVOKE, I'm assuming that it's
OFFLOAD_CANCEL?

Question:
In 15.2.3, 6th paragraph, it says:

  For an intra-server copy, both the ca_src_stateid and ca_dst_stateid
  MUST refer to either open or locking states provided earlier by the
  server.

Can this be a delegation stateid?  Or it must be open stateid or
locking stateid? (my question is for intra-server copy as well).

Also in general, if a client has a delegation for the source file it's
copying and allowed to use it for the copy, should there be some
guidance in the spec regarding dealing with recall of that delegation.
Does the client must wait until the copy completes before returning
the delegation? I imagine that otherwise, the destination server that
uses that stateid in the READ can fail with a BAD_STATEID error.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 27 Feb 2015 08:42:20 -0800

> On Feb 24, 2015, at 1:12 PM, Olga Kornievskaia <[email-masked]> wrote:
> 
> Hi Tom,
> 
> Minor typos: 
> 1. I noticed that section 4.2.2, 3rd paragraph, has COPY_NOTICE instead of COPY_NOTIFY.

Thanks, fixed!

> 2. In 15.3.3, there is a mention of COPY_REVOKE, I'm assuming that it's OFFLOAD_CANCEL?

Ditto

> Can this be a delegation stateid?  Or it must be open stateid or locking stateid? (my question is for intra-server copy as well).
> 

I believe the thought process was that the client had to get a lock request in order to provide for the situation below. And according to Section 8.2.5 of 5661, the lock stateid would take precedence.

But yes, if the client had established a delegation, then according to that same Section, a delegation stateid should be used.

Any dissent?

If not, I’ll make a clarification to the text:

   For an intra-server copy, both the ca_src_stateid and ca_dst_stateid
   MUST refer to either delegation, locking, or open provided earlier by the
   server (See Section 4.4.1). The order of selection is explained in Section
   8.2.5 of [RFC5661].

> Also in general, if a client has a delegation for the source file it's copying and allowed to use it for the copy, should there be some guidance in the spec regarding dealing with recall of that delegation. Does the client must wait until the copy completes before returning the delegation? I imagine that otherwise, the destination server that uses that stateid in the READ can fail with a BAD_STATEID error.
> 
> 

This is expected behavior and why we want the destination to have the stateid.