Subject: [nfsv4] [PATCH] Clarify the use of the copy offload stateid

From: Thomas Haynes <[email-masked]>
Date: Thu, 21 Aug 2014 10:47:55 -0700

From: Tom Haynes <[email-masked]>

Signed-off-by: Tom Haynes <[email-masked]>
---
 nfsv42_middle_copy.xml | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/nfsv42_middle_copy.xml b/nfsv42_middle_copy.xml
index 7aff891..aaa789d 100644
--- a/nfsv42_middle_copy.xml
+++ b/nfsv42_middle_copy.xml
@@ -44,7 +44,7 @@
     <t>
       The new operations are designed to copy files. Other
       file system objects can be copied by building on these operations
-      or using other techniques. For example if the user wishes to copy
+      or using other techniques. For example, if the user wishes to copy
       a directory, the client can synthesize a directory copy by first
       creating the destination directory and then copying the source
       directory's files to the new destination directory.
@@ -595,6 +595,17 @@
       copy offload operation using a stateid with seqid of 0.  Therefore a
       copy offload stateid with seqid of 0 MUST be considered invalid.
     </t>
+
+    <t>
+      In the context of an inter-server copy, the copy offload
+      stateid is actually issued to the client and not the destination
+      server. As such, there might already be an outstanding stateid,
+      issued to the destination as client of the source, with the
+      same value as that provided for the copy offload stateid. The
+      source MUST equate the copy offload stateid as that of the
+      client, i.e., when the destination presents it in the context
+      of a inter-server copy, it is on behalf of the client.
+    </t>
   </section>
 
   <section anchor="ss:copy:security" title="Security Considerations">
-- 
1.9.3

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 21 Aug 2014 14:16:11 -0400

> +++ b/nfsv42_middle_copy.xml

The copy offload stateid is used to track the state of the copy
offload operation according to section 4.9, and is returned by the
destination to the client as part of the COPY4res structure. Why would
that ever need to be presented to the source server?

The way I thought I understood the spec, the destination server gets
sent the ca_src_stateid, and the ca_dst_stateid as part of the COPY
operation. Both of those designate file locking state, not copy
offload state, with the ca_src_stateid designating the stateid that
can be used by the destination server for the READ operation. Am I
wrong?

Trond