Rick wrote: >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.) Tested it and it does not work, at least for Fedora30. The server just returns 0 instead of doing a copy to EOF on the input file. I think you should implement this, although my client does not do this now. >>A call with len=0 sounds like a different case. Yes, as above. >> >>--b. rick
