Re: NFSv4.2 server replies to Copy with length == 0

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 [email protected]...

> 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?

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4