On Tue, Feb 14, 2017 at 08:07:48PM +0000, Mora, Jorge wrote: > I can understand failing with NFS4ERR_INVAL when the source offset is beyond the end of the file, > 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? > Can the COPY return a count less than what it requested (a short copy)? > > As of right now, the implementation on the Linux server adheres to the spec That's weird, do you have network traces showing that, or is it possible the EINVAL is happening on the client side? >From a quick look at the server code I can't see where it would be generating that EINVAL, but I haven't tested this case and I could be overlooking something.... --b. > but copy_file_range succeeds > > when it is called against the local file system, NFSv4.x or NFSv3. > 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
