On Wed, Feb 15, 2017 at 5:36 AM, Kinglong Mee <kinglongmee@xxxxxxxxx> wrote: > On 2/15/2017 04:07, Mora, Jorge wrote: >> Hello, >> >> The NFSv4.2 spec (RFC 7862) on section 15.2.3 (COPY description) says the following: >> >> If the source offset or the source offset plus count is greater than >> the size of the source file, the operation MUST fail with >> NFS4ERR_INVAL. >> >> I can understand failing with NFS4ERR_INVAL when the source offset is beyond the end of the file, > > Yes, that's right. > >> but do you think failing with NFS4ERR_INVAL is too strict when the source offset plus the count is beyond the end of the file? >> What is the rationalization for failing on this specific instance? >> Why not return a short copy instead? > > The man-pages of copy_file_range description as, > > EINVAL Requested range extends beyond the end of the source file; or > the flags argument is not 0. > > So, the specific instance you said isn't allowed. > >> Can the COPY return a count less than what it requested (a short copy)? > > Yes, the return value of copy_file_range is, > > RETURN VALUE > Upon successful completion, copy_file_range() will return the number of > bytes copied between files. This could be less than the length origi‐ > nally requested. > >> >> As of right now, the implementation on the Linux server adheres to the spec but copy_file_range succeeds >> when it is called against the local file system, NFSv4.x or NFSv3. > > NFSv3 doesn't support copy_file_range, and only NFSv4.2 supports copy_file_range. copy_file_range() can be called with two file description that are from the NFSv3 mounts and currently as you point NFSv3 does not support copy_file_range() vfs_copy_file_range() will fall back into doing "normal" copy via do_splice_direct() what happens here is that NFSv3 will not fail with EINVAL and instead will return a partial copy. Thus as Jorge points out, we have inconsistent results of a copy being done via an NFS protocol v3 vs 4.2 protocol (if we were to enforce the rule that the spec says). >> For the local file system, NFSv4.x or NFSv3 copy_file_range falls back to regular copy by >> reading from the source file and then writing to the destination file but I do believe the >> syscall should be consistent regardless of the underlying file system. >> >> >> --Jorge >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
