Subject: [nfsv4] NFSv4.2 draft 30 Inter server to server corrections

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 20 Feb 2015 17:23:23 +0000

Hi Tom

1) COPY NFS4ERR_STALE clarification

15.2.3.  DESCRIPTION

   If the request is for a server-to-server copy, the source-fh is a
                                ^^^^^^^^^^^^^^^^^^^
This should be “an inter-server-to-server copy"

   filehandle from the source server and the compound procedure is being
   executed on the destination server.  In this case, the source-fh is a
   foreign filehandle on the server receiving the COPY request.  If
   either PUTFH or SAVEFH checked the validity of the filehandle, the
   operation would likely fail and return NFS4ERR_STALE.

   If a server supports the server-to-server COPY feature, a PUTFH
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be “For an inter-server copy”, a PUTFH

   followed by a SAVEFH MUST NOT return NFS4ERR_STALE for either
   operation.  These restrictions do not pose substantial difficulties
   for servers.  The CURRENT_FH and SAVED_FH may be validated in the
   context of the operation referencing them and an NFS4ERR_STALE error
   returned for an invalid file handle at that point.

2) Inter-server copy using NFSv4.x and source server clientid check on the READ stateid.

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.

We need to add some text here concerning the source server receiving the ca_src_stateid in an NFSv4.x READ operation from the destination server. At issue is the fact that the destination server will present the cn_src_stateid under a different clientID (perhaps no clientID in the case of NFSv4.0)  to the source server than the clientID that the cn_src_stateid was created under (the client clientID at OPEN or OPEN/LOCK). So it should be made clear that in the case of an inter-server copy that uses NFSv4.x as the copy protocol, the source server should expect and allow a different clientID for the READ stateid coming from the destination server for a file handle/statied pair ‘registered’ via a COPY_NOTIFY. In other words, an error such as NFS4ERR_BAD_STATEID should not be returned for the case of a clientID  cn_src_stateid mis-match.

—>Andy

---

From: Tom Haynes <[email-masked]>
Date: Fri, 27 Feb 2015 11:21:09 -0800

> On Feb 20, 2015, at 9:23 AM, Adamson, Andy <[email-masked]> wrote:
> 
> Hi Tom
> 
> This should be “an inter-server-to-server copy”

Ack

>   If a server supports the server-to-server COPY feature, a PUTFH

Ack

> We need to add some text here concerning the source server receiving the ca_src_stateid in an NFSv4.x READ operation from the destination server. At issue is the fact that the destination server wi…

I don’t mind making  the clarification, but to me it is obvious. But then again, I don’t want to be there as everyone implements it.

How about this:

For an inter-server copy that uses NFSv4.x as the copy protocol,
the source server MUST not return  NFS4ERR_BAD_STATEID
if the destination server presents a different clientid than that
provided during the COPY_NOTIFY. The source also MUST
map the relevant copy stateids to belong to the clientid established
by the client and not the destination.

Hmm, I don’t like that last sentence, perhaps you can take a whack at it?

Thanks for bringing this up!