Subject: [nfsv4] [PATCH] Have the OFFLOAD_STATUS be generic

From: Thomas Haynes <[email-masked]>
Date: Tue, 13 May 2014 08:51:00 -0700

From: Tom Haynes <[email-masked]>

Built on top of the OFFLOAD_CANCEL patch I just sent out.

This straightens out the text in OFFLOAD_STATUS to focus
on the generic need and not the COPY speficics.

Also, all of the verbage about REQUIREMENTs for which
op is needed is already given in the main COPY overview,
so axe that stuff out!

Signed-off-by: Tom Haynes <[email-masked]>
---
 dotx.d/offload_status_res.x         |  2 +-
 nfsv42_middle_op_copy_notify.xml    | 28 ++++++++++------------------
 nfsv42_middle_op_offload_cancel.xml |  5 -----
 nfsv42_middle_op_offload_status.xml | 37 +++++++++++++------------------------
 4 files changed, 24 insertions(+), 48 deletions(-)

diff --git a/dotx.d/offload_status_res.x b/dotx.d/offload_status_res.x
index a64f25e..d43121f 100644
--- a/dotx.d/offload_status_res.x
+++ b/dotx.d/offload_status_res.x
@@ -1,5 +1,5 @@
 struct OFFLOAD_STATUS4resok {
-	length4		osr_bytes_copied;
+	length4		osr_count;
 	nfsstat4	osr_complete<1>;
 };
 
diff --git a/nfsv42_middle_op_copy_notify.xml b/nfsv42_middle_op_copy_notify.xml
index dcca637..502c8ea 100644
--- a/nfsv42_middle_op_copy_notify.xml
+++ b/nfsv42_middle_op_copy_notify.xml
@@ -58,27 +58,19 @@
     </t>
 
     <t>
-      The cnr_lease_time is chosen by the source server. A
-      cnr_lease_time of 0 (zero) indicates an infinite lease.
-      To avoid the need for synchronized clocks, copy lease times
-      are granted by the server as a time delta.
-      To renew the copy lease time the client should resend the same
-      copy notification request to the source server.
+      The cnr_lease_time is chosen by the source server. A cnr_lease_time
+      of 0 (zero) indicates an infinite lease.  To avoid the need for
+      synchronized clocks, copy lease times are granted by the server
+      as a time delta.  To renew the copy lease time the client should
+      resend the same copy notification request to the source server.
     </t>
 
     <t>
-      A successful response will also contain a list of netloc4
-      network location formats
-      called cnr_source_server, on which the source is willing to
-      accept connections from the destination. These might not be reachable
-      from the client and might be located on networks to which the client
-      has no connection.
-    </t>
-
-    <t>
-      If the client wishes to perform an inter-server copy, the client
-      MUST send a COPY_NOTIFY to the source server. Therefore, the source
-      server MUST support COPY_NOTIFY.
+      A successful response will also contain a list of netloc4 network
+      location formats called cnr_source_server, on which the source is
+      willing to accept connections from the destination. These might
+      not be reachable from the client and might be located on networks
+      to which the client has no connection.
     </t>
 
     <t>
diff --git a/nfsv42_middle_op_offload_cancel.xml b/nfsv42_middle_op_offload_cancel.xml
index 10f8db5..9b1a9d8 100644
--- a/nfsv42_middle_op_offload_cancel.xml
+++ b/nfsv42_middle_op_offload_cancel.xml
@@ -35,10 +35,5 @@
       server's ability to read the source file and all copy operations
       on the source file have been completed.
     </t>
-
-    <t>
-      If the server supports COPY_NOTIFY, the server is REQUIRED to
-      support the OFFLOAD_CANCEL operation.
-    </t>
   </section>
 </section>
diff --git a/nfsv42_middle_op_offload_status.xml b/nfsv42_middle_op_offload_status.xml
index 2254c4f..10b8509 100644
--- a/nfsv42_middle_op_offload_status.xml
+++ b/nfsv42_middle_op_offload_status.xml
@@ -1,7 +1,7 @@
-<!-- Copyright (C) The IETF Trust (2011-2012) -->
-<!-- Copyright (C) The Internet Society (2011-2012) -->
+<!-- Copyright (C) The IETF Trust (2011-2014) -->
+<!-- Copyright (C) The Internet Society (2011-2014) -->
 
-<section anchor="op:offload_status" title="Operation 66: OFFLOAD_STATUS - Poll for status of a server-side copy">
+<section anchor="op:offload_status" title="Operation 66: OFFLOAD_STATUS - Poll for status of asynchronous operation">
   <section toc='exclude' title="ARGUMENT">
     <?rfc include='autogen/offload_status_args.xml'?>
   </section>
@@ -12,35 +12,24 @@
 
   <section toc='exclude' title="DESCRIPTION">
     <t>
-      OFFLOAD_STATUS is used for both intra-server and inter-server
-      asynchronous copies. The OFFLOAD_STATUS operation allows the
-      client to poll the destination server to determine the status
-      of an asynchronous copy operation.
+      OFFLOAD_STATUS can be used by the client to query the progress of an
+      asynchronous operation, which is identifed both by CURRENT_FH and
+      the osa_stateid.  If this operation is successful, the number of
+      bytes processed are returned to the client in the osr_count
+      field.
     </t>
 
     <t>
-      If this operation is successful, the number of bytes copied
-      are returned to the client in the osr_bytes_copied field. The
-      osr_bytes_copied value indicates the number of bytes copied
-      but not which specific bytes have been copied.
-    </t>
-
-    <t>
-      If the optional osr_complete field is present, the copy has
-      completed. In this case the status value indicates the result
-      of the asynchronous copy operation. In all cases, the server
-      will also deliver the final results of the asynchronous copy
+      If the optional osr_complete field is present, the asynchronous
+      operation has completed. In this case the status value indicates
+      the result of the asynchronous operation. In all cases, the server
+      will also deliver the final results of the asynchronous operation
       in a CB_OFFLOAD operation.
     </t>
 
     <t>
       The failure of this operation does not indicate the result of
-      the asynchronous copy in any way.
-    </t>
-
-    <t>
-      If the server supports asynchronous copies, the server is
-      REQUIRED to support the OFFLOAD_STATUS operation.
+      the asynchronous operation in any way.
     </t>
   </section>
 </section>
-- 
1.9.0

---

From: Christoph Hellwig <[email-masked]>
Date: Tue, 13 May 2014 18:45:10 +0200

Looks good, but it seems some unrelated COPY_NOTIFY changes sneaked in here.