Re: NFSv4.2 server replies to Copy with length == 0
Daniel Gryniewicz <[email protected]>
| Newsgroups | gmane.ietf.nfsv4 |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
On 10/21/19 10:24 AM, Rick Macklem wrote: > Frank Filz wrote: >>> (That's why I've asked other implementors to put their hands up and, > sofar, >>> there hasn't been any hands up. I thought Ganesha was working on NFSv4.2, > but >>> no one has posted on [email protected] about it.) >> >> Sorry no one from Ganesha has raised their hand. I have been watching this >> discussion, but we have limited 4.2 support. As far as I know, no one has >> implemented server side copy on Ganesha. > Along with the Copy ones, there is the problem I brought up a while ago w.r.t > Seek. I recall Ganesha did encounter that one? > The case is: > Seek > Arguments: > sa_offset: <file_size> > sa_what: NFS4_CONTENT_DATA > > Reply that Linux client expects: > (A) NFS4ERR_INVAL > whereas the RFC seems to indicate > (B) NFS_OK > sr_eof: true > sr_offset: <file_size> > > Which of these does you current code implement? > (If it is (B), the code I posted will break when run on a Linux client > against your server.) We currently return NFS4ERR_NXIO for >= <file_size>. Reading the spec, this should probably only be > <files_size>. We don't explicitly deal with DATA at the end, it's currently delegated to the clustered filesystem implementation, so I don't know what we'd return if we fixed this check. So we currently to neither of those two things. > > Has this code shipped to users yet? Yes. However, the downstreams don't support it yet. We have a history of changing our behavior to be spec compliant, anyway, so we're happy to change. Daniel _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4