Subject: [nfsv4] NFSv4.2, WG LC, CLONE, and COPY

From: Tom Haynes <[email-masked]>
Date: Mon, 30 Mar 2015 13:29:48 -0700

In Dallas, we decided to take the CLONE operation and to see if we can reach consensus on the inter and intra server COPY approaches.

As such, draft-35 has the CLONE operation and the recent changes to the COPY text proposed by Christoph?

My take is that everyone is fine with the intra-server copy.

Andy and Olga, for the inter-server copy, does the additional stateid solve the issues you were seeing? Is there
anything else outstanding on it?

Christoph, besides the questions you just asked, are there any issues that stand in the way for you?

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 30 Mar 2015 20:31:59 +0000

And when can we start a last call for these changes, etc....?

> -----Original Message-----
> From: nfsv4 [mailto:[email-masked]] On Behalf Of Tom Haynes
> Sent: Monday, March 30, 2015 1:30 PM
> To: NFSv4
> Cc: Andy Adamson; Olga Kornievskaia; Christoph Hellwig
> Subject: [nfsv4] NFSv4.2, WG LC, CLONE, and COPY
> 
> In Dallas, we decided to take the CLONE operation and to see if we can reach
> consensus on the inter and intra server COPY approaches.
> 
> Andy and Olga, for the inter-server copy, does the additional stateid solve
> the issues you were seeing? Is there anything else outstanding on it?
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Christoph Hellwig <[email-masked]>
Date: Tue, 31 Mar 2015 11:13:41 +0200

> Christoph, besides the questions you just asked, are there any issues that stand in the way for you?

I've not found anything else, but unlike intra-server COPY and CLONE I
haven't looked at implementations.

---

From: Anna Schumaker <[email-masked]>
Date: Tue, 31 Mar 2015 09:15:00 -0400

> haven't looked at implementations.

Could intra-server COPY be replaced completely with CLONE?  Maybe by adding in an extra argument for saying that the file should be copied even if acceleration isn't possible?

Anna

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 31 Mar 2015 13:30:27 +0000

> On Mar 31, 2015, at 9:15 AM, Anna Schumaker <[email-masked]> wrote:
> 

Yes - I also think both a CLONE and intra server COPY overlap. Marc Eshel mentioned that he would implement CLONE but not COPY due to the complexity of COPY. I think that all the COPY complexity is in the inter-server case, and that having a CLONE for intra server and a COPY for inter server only makes the most sense if possible.

—>Andy

---

From: David Noveck <[email-masked]>
Date: Tue, 31 Mar 2015 09:50:37 -0400

The big question is whether we need two operations or one.

If we decide on one, I'd prefer that it be called COPY, even if cloning is
a likely optimization in many cases.  That
make the possible transition to the inter-server case cleaner.

If we did that, the text should make clear that cloning is a
valid/desirable implementation of COPY.  Also,
that if a COPY cannot be done as a clone because of alignment
considerations, it is valid to clone the
aligned portion (assuming compatible source and destination alignments)
while copying any initial and
final fragments.

Also you'd need two flag bits (and appropriate error codes):

   - A bit that says the operation should be failed if it cannot be done
   synchronously.
   - A bit that says the operation should be failed if it cannot be done
   atomically.

CLONE would then become COPY with both of these bits set.

On Tue, Mar 31, 2015 at 9:15 AM, Anna Schumaker <[email-masked]>
wrote:

> >> Andy and Olga, for the inter-server copy, does the additional stateid
> solve the issues you were seeing? Is there
> Could intra-server COPY be replaced completely with CLONE?  Maybe by
> adding in an extra argument for saying that the file should be copied even
> if acceleration isn't possible?
>
> Anna
>
> >

---

From: Tom Haynes <[email-masked]>
Date: Tue, 31 Mar 2015 08:27:49 -0700

Historically, we tend to smash many functions into one operation - and it becomes a swiss army knife.

I like the separation of COPY and CLONE. It makes the client side handling easier.

> On Mar 31, 2015, at 6:50 AM, David Noveck <[email-masked]> wrote:
> 
> If we decide on one, I'd prefer that it be called COPY, even if cloning is a likely optimization in many cases.  That
> If we did that, the text should make clear that cloning is a valid/desirable implementation of COPY.  Also, 
> that if a COPY cannot be done as a clone because of alignment considerations, it is valid to clone the 
> aligned portion (assuming compatible source and destination alignments) while copying any initial and 
> final fragments.
> 
> A bit that says the operation should be failed if it cannot be done synchronously.
> A bit that says the operation should be failed if it cannot be done atomically.
> On Tue, Mar 31, 2015 at 9:15 AM, Anna Schumaker <[email-masked] <mailto:[email-masked]>> wrote:
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
> >
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>

---

From: Christoph Hellwig <[email-masked]>
Date: Tue, 31 Mar 2015 18:04:46 +0200

> Yes - I also think both a CLONE and intra server COPY overlap. Marc Eshel mentioned that he would implement CLONE but not COPY due to the complexity of COPY. I think that all the COPY complexity is…

This assumes two things:

 (a) no server needs the asyc support for local copies
 (b) every server can do local copies atomically

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 31 Mar 2015 16:18:30 +0000

> On Mar 31, 2015, at 12:04 PM, Christoph Hellwig <[email-masked]> wrote:
> 

What I mean is that CLONE would offer the async and non-atomic portion of intra server COPY as a choice by the server if allowed by the client. Right now COPY has the ca_synchronous flag. Perhaps add a ca_atomic flag. Add the ca_synchronous and a ca_atomic flag to CLONE?

Perhaps it’s cramming too much into one call.

—>Andy