Subject: [nfsv4] Summary of Design Review on 7/30/12

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 1 Aug 2012 23:39:15 +0000

We took the opportunity at the IETF meeting to hold an additional Design Review
meeting to go over the three major unresolved issues. I'll present the rough
notes that Spencer took (thanks!), but I'm also going to summarize the issues:

1) Server-Side Copy - How do we issue locks and have other clients honor
locks on both the source and the destination?

What we decided in the meeting was to leverage existing NFSv4 sematics
for locking a file to allow the client to do this for us. We've changed
the copy-offload from being meta-data and data offload to just being
data offload.

The client MUST open the source and destination files. It SHOULD issue
locks (either share or byte level) to make sure it is not violating
any outstanding locks and to prevent other clients from changing contents.

Here is the draft-13 approach:

     Client                Source         Destination
        +                    +                 +
        |                    |                 |
        |--- COPY_NOTIFY --->|                 |
        |<------------------/|                 |
        |                    |                 |
        |                    |                 |
        |--- COPY ---------------------------->|
        |<------------------------------------/|
        |                    |                 |
        |                    |                 |
        |                    |<----- read -----|
        |                    |\--------------->|
        |                    |                 |
        |                    |        .        | Multiple reads may
        |                    |        .        | be necessary
        |                    |        .        |
        |                    |                 |
        |                    |                 |
        |--- COPY_STATUS --------------------->| Client may poll
        |<------------------------------------/| for status
        |                    |                 |
        |                    |        .        | Multiple COPY_STATUS
        |                    |        .        | operations may be sent
        |                    |        .        |
        |                    |                 |
        |                    |                 |
        |                    |                 |
        |<-- CB_COPY --------------------------| Destination reports
        |\------------------------------------>| results
        |                    |                 |

Here is the new proposed scheme:

     Client                Source         Destination
        +                    +                 +
        |                    |                 |
        |--- OPEN        --->|                 | Returns os1
        |<------------------/|                 |
        |                    |                 |
        |--- LOCK        --->|                 | Optional, could be done
        |<------------------/|                 | with a share lock
        |                    |                 |
        |--- COPY_NOTIFY --->|                 | Need to pass in os1 or lock state
        |<------------------/|                 |
        |                    |                 |
        |                    |                 |
        |                    |                 |
        |--- OPEN ---------------------------->| Returns os2
        |<------------------------------------/|
        |                    |                 |
        |--- LOCK ---------------------------->| Optional ...
        |<------------------------------------/|
        |                    |                 |
        |--- COPY ---------------------------->| Need to pass in os2 or lock state
        |<------------------------------------/|
        |                    |                 |
        |                    |                 |
        |                    |<----- read -----|
        |                    |\--------------->|
        |                    |                 |
        |                    |        .        | Multiple reads may
        |                    |        .        | be necessary
        |                    |        .        |
        |                    |                 |
        |                    |                 |
        |--- COPY_STATUS --------------------->| Client may poll
        |<------------------------------------/| for status
        |                    |                 |
        |                    |        .        | Multiple COPY_STATUS
        |                    |        .        | operations may be sent
        |                    |        .        |
        |                    |                 |
        |                    |                 |
        |                    |                 |
        |<-- CB_COPY --------------------------| Destination reports
        |\------------------------------------>| results
        |                    |                 |
        |--- LOCKU --------------------------->| Only if LOCK was done
        |<------------------------------------/|
        |                    |                 |
        |--- CLOSE --------------------------->| Release open state
        |<------------------------------------/|
        |                    |                 |
        |--- LOCKU       --->|                 | Only if LOCK was done
        |<------------------/|                 |
        |                    |                 |
        |--- CLOSE       --->|                 | Release open state
        |<------------------/|                 |
        |                    |                 |

An new issue was raised as to how the destination and client keep
credentials fresh.

2) Space reservations

The main consensus was that we needed to clarify the intended behavior.

3) Holes and INITIALIZE

We've known since the start that hole punching could be asynchornous. On several
occasions, we've mentioned that this is just an Intra-Server Server-Side Copy,
basically between /dev/zero and the target file. :->

The consensus reached is to rename the COPY* operations to be OFFLOAD* as
needed and use them to control an asynchronous INITIALIZE.

Here are Spencer's raw notes:

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 2 Aug 2012 01:24:33 +0000

So does this mean that COPY now takes a stateid argument? If not, then I’d like to propose further changes.

Cheers
  Trond

From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Wednesday, August 01, 2012 7:39 PM
To: nfsv4 list
Subject: [nfsv4] Summary of Design Review on 7/30/12

2) Space reservations

3) Holes and INITIALIZE

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 2 Aug 2012 14:53:38 +0000

Hey, Trond.

Yes, COPY and others would use stateids as needed.  To restate what Tom captured, the model is to rely on the current OPEN(share-mode)/LOCK/READ/WRITE/CLOSE mechanisms.  Server-to-server copy is thus an optimization of the client's normal READ/WRITE behavior that would be undertaken to move data.  Thus, "we" get the normal state handling from OPEN/CLOSE as usual.  If the client wants to coordinate sharing it can do so with the familiar model and the source/destination servers will "know" what to do.  This also helps with multi-stream copies such that the client can instantiate those easily as well.

Spencer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Wednesday, August 1, 2012 6:25 PM
To: Haynes, Tom; nfsv4 list
Subject: Re: [nfsv4] Summary of Design Review on 7/30/12

So does this mean that COPY now takes a stateid argument? If not, then I'd like to propose further changes.

Cheers
  Trond

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Haynes, Tom
Sent: Wednesday, August 01, 2012 7:39 PM
To: nfsv4 list
Subject: [nfsv4] Summary of Design Review on 7/30/12

2) Space reservations

3) Holes and INITIALIZE

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 2 Aug 2012 15:13:37 +0000

Excellent! I look forward to reviewing the draft rfc when it is
updated...

Cheers
  Trond

On Thu, 2012-08-02 at 14:53 +0000, Spencer Shepler wrote:
>  
> 
> Hey, Trond.
> 
>  
> 
> Yes, COPY and others would use stateids as needed.  To restate what
> Tom captured, the model is to rely on the current
> OPEN(share-mode)/LOCK/READ/WRITE/CLOSE mechanisms.  Server-to-server
> copy is thus an optimization of the client’s normal READ/WRITE
> behavior that would be undertaken to move data.  Thus, “we” get the
> normal state handling from OPEN/CLOSE as usual.  If the client wants
> to coordinate sharing it can do so with the familiar model and the
> source/destination servers will “know” what to do.  This also helps
> with multi-stream copies such that the client can instantiate those
> easily as well.
> 
>  
> 
> Spencer
> 
>  
> 
>  
> 
> From:[email-masked] [mailto:[email-masked]] On Behalf
> Of Haynes, Tom
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Thu, 2 Aug 2012 12:50:20 -0400

I believe it means that COPY will take two stateid arguments: one for the source and one for the destination.  I'm not positive about that, though.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Myklebust, Trond
Sent: Wednesday, August 01, 2012 9:25 PM
To: Haynes, Tom; nfsv4 list
Subject: Re: [nfsv4] Summary of Design Review on 7/30/12

Cheers
  Trond

2) Space reservations

3) Holes and INITIALIZE