On 10/17/2019 11:22 AM, 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?
Those manpages look like ENXIO comes back only on sparse files. Perhaps
this is boilerplate from v4.0 before this kind of thing was common.
This should at least be discussed on nfsv4@xxxxxxxx...
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.
What Bad Thing would happen for the difference?
