Re: [nfsv4] Server-side copy question

[Thomas Haynes <[e-mail]>]

On Feb 16, 2017, at 5:00 AM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

> 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,
> 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?

Yes.

> What is the rationalization for failing on this specific instance?

I don't know of any.

> Why not return a short copy instead?

If the question is "why not actually implement a server to return a short copy", you could probably do that and get way with it but it is generally better to follow the spec, even if mistaken, unless something horrendous would occur by following it.

If the question is "why doesn't the spec allow you to return a short copy?", I don't know.  I think this is probably just a mistake that wasn't caught in time.

If the question is "why can't the spec be fixed to allow return of a short copy?", it can, in theory, but it is probably not worth the effort.  You can file an erratta, but since this is asking for a change in behavior, there will be a lot of resistance, especially since the word "MUST" is used.


No, I’d file an errata with the justification that implementations we are trying to be compatible with are not compatible with the existing language.



BTW, the word "MUST" probably shouldn't be there since RFC 2119 says:

Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)

> 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.
> 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.

I agree but think that the most expedient way of addressing this problem is in the Linux client,  It can check against the file size before issuing the COPY request  to prevent an erroneous INVAL error being returned.

On Wed, Feb 15, 2017 at 5:19 PM, Mora, Jorge <[e-mail]<mailto:[e-mail]>> 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,
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?

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.
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

_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4


_______________________________________________
nfsv4 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nfsv4