Re: Scribe NFSv4.2 5/31

On Wed, 2012-06-20 at 16:21 +0000, Haynes, Tom wrote:
> 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

>   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 <Talia.Reyes-Ortiz <at> netapp.com>
> Date: Thursday, May 31, 2012 4:12 PM
> To: nfsv4 <nfsv4 <at> ietf.org>
> Subject: [nfsv4] Scribe NFSv4.2 5/31
> 
> 
> 
> 3063 – AI Trond: Raise change from this line in discussion
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 <at> ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4