Re: [nfsv4] Server-side copy question

[David Noveck <[e-mail]>]

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


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]> 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]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>