>J. Bruce Fields wrote: >On Thu, Oct 17, 2019 at 02:16:36AM +0000, Rick Macklem wrote: >> 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). > >Huh. Looks like that's documented behavior of Linux's seek. (See the >ERRORS section of the lseek(2) man page.) Looks like Solaris also >returns -ENXIO in this case: > > https://docs.oracle.com/cd/E26502_01/html/E29032/lseek-2.html > >And freebsd too: > > https://www.freebsd.org/cgi/man.cgi?query=lseek&sektion=2 > >I wonder where that spec language came from? Agreed that it is the POSIX draft behaviour. And, yes, I don't know why the RFC specifies it differently, but when I discussed it on nfsv4@xxxxxxxx, the concensus was that the RFC indicated a reply of: NFS_OK, sr_eof == true, sr_offset == file_size for a request of: sa_offset == file_size, sa_what == NFS4_CONTENT_DATA (In the nfsv4@xxxxxxxx archive dated around 2019-08-12.) >Our NFS server could translate an -ENXIO return into 0 and sr_eof == >true easily enough, assuming -ENXIO is really only ever returned in that >case. > >I haven't tested, but from a quick check of the Linux client code I >think that would require a matching fix on the client side to translate >sr_eof == 0 *back* to ENXIO. > >I don't know if it's worth it. Yep, agreed. All the FreeBSD client does is what you stated above, mapping sr_eof == true -> ENXIO for the NFS4_CONTENT_DATA case. rick ps: When I re-read it, the comment I made related to Bruce's "wrong" was blunt (or maybe rude). I apologize for the tone. All I had intended to say was "although it might not be our preferred semantic, it appears to clear and implementable, so I do not think it can be "clarified" to be the way the Linux server does it". I actually prefer the way the Linux server does it, but it is too late now, imho. --b.
