Subject: [nfsv4] 4.2 COPY op questions

From: Brian Reitz <[email-masked]>
Date: Mon, 28 Jul 2014 16:28:06 -0500

I raised a question about the 4.2 server-to-server copy spec language wrt delegations during IETF 90.  Specifically a write delegation.  I committed to taking that question to this list for more discussion.  

If the client that has initiated a server-to-server copy holds a write delegation it may also hold unwritten data that the source server has not seen.  If the COPY op does not cause a delegation recall the client would need to ensure that this unwritten data is flushed prior to initiating the copy.  That might be a quality of implementation detail.  The possibility exists to use NFSv4.x as the Copy Protocol.   If an implementor was going to use NFSv4.x as the Copy Protocol, a general client implementation on the destination server doing a read might reasonably expect the source server to initiate a deleg recall, unless it is expected that the READ on the destination server can skip the OPEN by using arguments in the COPY op.   I think it would be helpful if the spec had additional clarifying language here detailing the expected behavior and relationship to delegations.

I also have a question around the stateids that are passed to the destination server in a COPY op:

     4.7.2.  Using NFSv4.x as the Copy Protocol

     The destination server MAY use standard NFSv4.x (where x >= 1)
     operations to read the data from the source server.  If NFSv4.x is
     used for the server-to-server copy protocol, the destination server
     can use the source filehandle and ca_src_stateid provided in the COPY
     request with standard NFSv4.x operations to read data from the source
     server.

I believe that this spec language is talking about what an implementer MAY do, and how these stateids might be used.  I think it may also be helpful to have additional clarifying language here indicating the different scoping of a stateid.  The implication to the implementor here is that these stateids can be used by multiple clients.  That is something that is not required by 5661.  From 5661 section 8.2:
  
    The server may assign stateids independently for different clients.
     A stateid with the same bit pattern for one client may designate an
     entirely different set of locks for a different client.  The stateid
     is always interpreted with respect to the client ID associated with
     the current session.  Stateids apply to all sessions associated with
     the given client ID, and the client may use a stateid obtained from
     one session on another session associated with the same client ID.

It might be helpful to clarify that the stateids passed in the COPY would need to be implemented such that they had a broader scope than what is detailed in 5661.

Brian

---

From: Tom Haynes <[email-masked]>
Date: Thu, 31 Jul 2014 16:13:11 -0400

On Jul 28, 2014, at 5:28 PM, Brian Reitz <[email-masked]> wrote:

> I believe that this spec language is talking about what an implementer MAY do,

The MAY above refers to you may use NFSv4.1.

> and how these stateids might be used.  I think it may also be helpful to have additional clarifying language here indicating the different scoping of a stateid.  The implication to the implementor here is that these stateids can be used by multiple clients.

It is stronger than an implication, it is mandated. The destination server may already be
a client to the source server and already have a stateid with exactly the same bits as the
one the source handed to the client. However, those two stateids are different!

The destination is acting on behalf of the client and as such, it has to use the client’s
stateid.

I’ll think about how to polish that point up.

Thanks

>  That is something that is not required by 5661.  From 5661 section 8.2:
> 

> Brian
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4