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

From: Christoph Hellwig <[email-masked]>
Date: Wed, 1 Apr 2015 09:01:48 +0200

On Tue, Mar 31, 2015 at 04:18:30PM +0000, Adamson, Andy 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.

That's exactly the crap I try to avoid.  Once we got all that bloat
we're essentially back to COPY as far as the operation defintion goes.

---

From: Tom Haynes <[email-masked]>
Date: Wed, 1 Apr 2015 10:08:43 -0700

I’m not seeing a huge outcry against this - lets start the counter…

> On Mar 30, 2015, at 1:31 PM, Spencer Shepler <[email-masked]> wrote:
> 
> 
> 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.
>> 
>> 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?
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: David Noveck <[email-masked]>
Date: Wed, 1 Apr 2015 13:33:08 -0400

---------- Forwarded message ----------
From: David Noveck <[email-masked]>
Date: Wed, Apr 1, 2015 at 1:27 PM
Subject: Re: [nfsv4] NFSv4.2, WG LC, CLONE, and COPY
To: Tom Haynes <[email-masked]>

I think two weeks is reasonable.

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 1 Apr 2015 17:50:01 +0000

> On Apr 1, 2015, at 1:08 PM, Tom Haynes <[email-masked]> wrote:
> 

I would like to fully understand the differences between synchronous inter-server COPY and CLONE.

Perhaps I’m wrong but these statements look to be true to me:

1) If a server exports a file system that supports COW, it will use it for synchronous Intra-server COPY.

2) If a server uses COW and the offset/count are block aligned, the COPY will be atomic.

3) For synchronous intra-server COPY support, there are no other required operations.

4)  If an ‘atomic’ flag were added to intra-server synchronous COPY along with the block alignment requirements when the atomic flag is used, we would have CLONE.

—>Andy

---

From: David Noveck <[email-masked]>
Date: Wed, 1 Apr 2015 14:54:29 -0400

> 1) If a server exports a file system that supports COW, it will use it
for synchronous Intra-server COPY.

It almost certainly will but it isn't required to.  i think the same is
true of clone.

> 2) If a server uses COW and the offset/count are block aligned, the COPY
will be atomic.

Most likely but it requires some sort of locking/single-threading to assure
atomicity.

> 3) For synchronous intra-server COPY support, there are no other required
operations.

 I think minorversion2-35 says OFFLOAD_{CANCEL,STATUS} are required for
both inter-server and intra-sever copy.

I think you cannot return NFS4ERR_NOTSUPP, but a server that does all
copies synchronously can return NFS4ERR_BAD_STATEID without looking at the
stateid.

Ugly, but simple and effective.

> 4)  If an ‘atomic’ flag were added to intra-server synchronous COPY along
with the block alignment requirements when the atomic flag is used, we
would have CLONE.

Yes, but we wouldn't have consensus ;-(

On Wed, Apr 1, 2015 at 1:50 PM, Adamson, Andy <[email-masked]>
wrote:

> 4)  If an ‘atomic’ flag were added to intra-server synchronous COPY along
> with the block alignment requirements when the atomic flag is used, we
> would have CLONE.
>
> —>Andy
>
> >>>

---

From: Christoph Hellwig <[email-masked]>
Date: Thu, 2 Apr 2015 11:35:12 +0200

> 1) If a server exports a file system that supports COW, it will use it for synchronous Intra-server COPY.

Will it? a COW clone with thrash preallocation status, which in the current
RFC language isn't allowed for COPY.  And even that assumes the server even
bothers to implement intra-server COPY.

> 2) If a server uses COW and the offset/count are block aligned, the COPY will be atomic.

Doesn't nessecarily have to be.  Bad implementations might need multiple
transactions for a clone, and if no one requires it to be atomic they could
leak this implementation detail out.  Unlikely, but possible.

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 2 Apr 2015 13:46:22 +0000

> On Apr 1, 2015, at 2:54 PM, David Noveck <[email-masked]> wrote:
> 
> It almost certainly will but it isn't required to.  i think the same is true of clone.
> 
> Most likely but it requires some sort of locking/single-threading to assure atomicity.
> 
>  I think minorversion2-35 says OFFLOAD_{CANCEL,STATUS} are required for both inter-server and intra-sever copy.

Well, what is true is that  for async intra-server COPY, there are no other required operations.

> 
> I think you cannot return NFS4ERR_NOTSUPP, but a server that does all copies synchronously can return NFS4ERR_BAD_STATEID without looking at the stateid.
> 

As you can tell, I still think having both a CLONE operation and an intra-server COPY operaion is bloat.

I will submit a patch to show what I mean.

—>Andy

> 
> On Wed, Apr 1, 2015 at 1:50 PM, Adamson, Andy <[email-masked]> wrote:
>

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 2 Apr 2015 13:53:02 +0000

> On Apr 2, 2015, at 9:46 AM, Adamson, Andy <[email-masked]> wrote:
> 
> 

Oops - I mean sync intra-server COPY :)

---

From: David Noveck <[email-masked]>
Date: Thu, 2 Apr 2015 10:41:46 -0400

> Oops - I mean sync intra-server COPY :)

Putting my version management hat on (according to Nico, it should have a
big O for "overwrought" on it ;-), without some significant change to
section 13 of the 4.2 spec, if you return NFS4ERR_NOTSUPP to an
OFFLOAD_STATUS or OFFLOAD_CANCEL, the client is justified in concluding
that the server does not support inter-server or intra-server copy.

As i said, if you don't support async copies, you can legitimately always
return NFS4ERR_BAD_STATEID so that you formally support these operations,
even though the support is trivial.

On Thu, Apr 2, 2015 at 9:53 AM, Adamson, Andy <[email-masked]>
wrote:

> >>> 4)  If an ‘atomic’ flag were added to intra-server synchronous COPY
> along with the block alignment requirements when the atomic flag is used,
> we would have CLONE.
> >>
> >> 4)  If an ‘atomic’ flag were added to intra-server synchronous COPY
> along with the block alignment requirements when the atomic flag is used,
> we would have CLONE.
> >>
> >> —>Andy
> >>
> >>>>>