Subject: Re: [nfsv4] Scribe NFSv4.2 5/31

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 20 Jun 2012 16:21:18 +0000

Do you recall what you wanted done here?

  3063     The ca_src_offset is the offset within the source file from which the
  3064     data will be read, the ca_dst_offset is the offset within the
  3065     destination file to which the data will be written, and the ca_count
  3066     is the number of bytes that will be copied.  An offset of 0 (zero)
  3067     specifies the start of the file.  A count of 0 (zero) requests that
  3068     all bytes from ca_src_offset through EOF be copied to the
  3069     destination.  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.  If the source file's end of file is
  3075     being modified in parallel with a copy that specifies a count of 0
  3076
  3077
  3078
  3079  Haynes                  Expires November 24, 2012              [Page 55]
  3080  ^L
  3081  Internet-Draft                   NFSv4.2                        May 2012
  3082
  3083
  3084     (zero) bytes, the amount of data copied is implementation dependent
  3085     (clients may guard against this case by specifying a non-zero count
  3086     value or preventing modification of the source file as mentioned
  3087     above).

From: <Reyes-Ortiz>, Talia <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 31, 2012 4:12 PM
To: nfsv4 <[email-masked]<mailto:[email-masked]>>
Subject: [nfsv4] Scribe NFSv4.2 5/31

3063 – AI Trond: Raise change from this line in discussion

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 20 Jun 2012 13:31:23 -0400

> Do you recall what you wanted done here?

This basically feeds into the discussion about whether or not the COPY
request needs to take an open/lock/delegation stateid arguments. I think
it does for 2 reasons:

1) The destination server needs to be able to enforce byte range and
share locks on the destination file. The text in the paragraph below
fails completely to take into account the fact that other NFS clients
may already hold locks on the destination file, or that they may acquire
locks on the destination file while the copy offload operation is still
in progress. If those cases, the copy offload should be made to respect
the locks in the same way that a 'cp' without copy offload would.

2) The source server needs to be able to do the same. If another client
sets a share lock on the source file with a DENY_READ, or it sets a
mandatory byte range lock with WRITE_LT, then the expectation should be
that any copy offload operation must fail; just as it would if we were
trying a 'cp' operation without copy offload.

Cheers
  Trond

> From: <Reyes-Ortiz>, Talia <[email-masked]>
> To: nfsv4 <[email-masked]>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4