I have added nfsv4@xxxxxxxx to the cc list, since I think it is important that
everyone involved in NFSv4.2 be aware of this.
>J. Bruce Fields wrote:
>On Wed, Oct 16, 2019 at 07:53:45PM +0000, Kornievskaia, Olga wrote:
>> On 10/16/19, 11:58 AM, "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote:
>> On Wed, Oct 16, 2019 at 06:22:42AM +0000, Rick Macklem wrote:
>> > It seems that the Copy reply with wr_count == 0 occurs when the
>> > client sends a Copy request with ca_src_offset beyond EOF in the
>> > input file. (It happened because I was testing an old/broken
>> > version of my client, but I can reproduce it, if you need a
>> > bugfix to be tested. I don't know if the case of
>> > ca_src_offset+ca_count beyond EOF behaves the same?) --> The RFC
>> > seems to require a reply of NFS4ERR_INVAL for this case.
>>
>> I've never understood that INVAL requirement. But I know it's
>> been discussed before, maybe there was some justification for it
>> that I've forgotten.
No longer overly relevant, since the RFC is now a published spec.
(It may have just been consistent with the old copy_file_range(2) semantics?)
>>
>> Sigh, well, I don’t know if we should consider adding the check to the
>> NFS server to be NFS spec compliant. VFS layer didn't want the check
>> and instead the preference has been to keep read() semantics of
>> returning a short read (when the len was beyond the end of the file or
>> if the source) to something beyond the end of the file.
>
>I'm inclined to think the spec's just wrong.
The RFC is not wrong, although it might not be your preferred semantic.
(It would only be wrong if it was unimplementable.)
As for patching the server, I am not sure if that is a good idea now or not?
- I would like to see the Linux NFSv4.2 server conform to the RFC, however
it has already shipped in its current form.
--> I think that all extant clients need to handle both reply semantics and,
once that is the case, patching the server to conform to the RFC would
be nice.
I have now found two cases where the Linux NFSv4.2 server does not conform
to RFC-7862. One is as above and the other is a reply to Seek of NFS4ERR_NXIO
when the sa_offset argument == file_size (instead of replying NFS_OK along
with sr_eof == true).
Since I now know about these two cases, I can code the client to handle
both of them. Of course, I do worry about others that I have not found yet.
>And how else could a client possibly interpret a 0 return?
The FreeBSD client looped, because it does a Copy in a loop until all bytes
were copied and, with a reply length == 0, it didn't make progress or
recognize an error.
Fortunately, this client is still under development (not yet released), so I can
add code to handle wr_count == 0 in the same way as NFS4ERR_INVAL.
>> On the client if VFS did read of len=0 then VFS itself we return 0,
>> thus this doesn't protect against other clients sending an NFS copy
>> with len=0. And in NFS, receiving copy with len=0 means copy to the
>> end of the file. It's not implemented for any "intra" or "inter" code.
Are you saying that an NFSv4.2 Copy request with a ca_count == 0
will not work for the Linux NFSv4.2 server?
(I guess I'd better test this one, too.)
>A call with len=0 sounds like a different case.
>
>--b.
rick
