Subject: [nfsv4] Copy offload semantics w.r.t. locking

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 1 Jun 2012 02:52:14 +0000

Hi,

In the review today, it was noticed that the current copy offload code
assumes that the destination server will take a passive role w.r.t.
locks. Specifically, draft-ietf-nfsv4-minorversion2-11.txt states that:

   3069                  If concurrent modifications to the source file overlap
   3070    with the source file region being copied, the data copied may include
   3071    all, some, or none of the modifications.  The client can use standard
   3072    NFS operations (e.g., OPEN with OPEN4_SHARE_DENY_WRITE or mandatory
   3073    byte range locks) to protect against concurrent modifications if the
   3074    client is concerned about this.

The question is this:

        - What happens if a network partition between the NFS client and
        the target server for the copy offload operation causes the
        share/byte range lock that is protecting the target file to be
        lost?

        IOW: how should the target server react if another client comes
        in and sets up a conflicting lock, once the lease expires for
        the original client that set up the copy offload operation?

In my opinion, the target server should be able to interrupt the copy
offload operation in the case where the locks on the target file are
lost. Since the target server is the one responsible for enforcing those
locks, it knows when a new lock is being set, and so should be able to
fence off any further changes to the file that would be in conflict with
that lock. This is consistent with the behaviour where the client is
reading from the source and then writing to the target...

Another situation where this is relevant is that where one client sets a
lock, and then someone starts a copy offload operation in conflict with
that lock...

---

There is a similar issue when the client sets a lock on the source
server: again that lock could be lost due to network partition issues,
in which case a second client that sets a DENY_READ share lock or a
mandatory byte range lock has a right to assume that the data covered by
the lock will NOT be copied to the target.

---

My proposal is therefore that we add a stateid argument to the COPY
operation to "struct COPY4args" in order to allow the target server to
enforce any write locks that may be in effect on the target side. In
particular, the target server would then be responsible for either
waiting for a copy offload operation to finish, or for cancelling the
remaining copy operation before granting a conflicting file/byte range
lock.

I'd also like to propose that we add a stateid argument to "struct
COPY_NOTIFY4args" in order to allow the source server to enforce any
read locks that may be set on the file from the server side.

It should still be possible for the client to specify any one of the
special stateids (see Section 8.2.3 in RFC5661) in order to avoid
specifying a locking state, or in order to specify the "current stateid"
for the compound containing the COPY/COPY_NOTIFY operation.

      * In the case where an "all zero" or "all one" special stateid is
        specified on the target, then I suggest that if a share lock or
        mandatory lock is established on the target device, then the
        copy offload operation MUST be cancelled.
      * In the case where an "all zero" stateid is specified on the
        source, then I suggest that the establishment of a conflicting
        share/mandatory lock on the source file MUST cause the copy
        offload operation to be cancelled.
      * In the case where an "all one" stateid is specified on the
        source, then I suggest that the establishment of a conflicting
        share/mandatory lock on the source file MAY cause the copy
        offload operation to be cancelled.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com