Tom Talpey wrote: >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. As far as I know, a non-sparse file (no holes) behaves the same as a file with holes in it. (I'm not sure if the POSIX draft is clear for the case where the file system does not support holes, but I think most implementations handle that the same way as a file with no holes on a file system that supports holes.) >This should at least be discussed on nfsv4@xxxxxxxx... I think there needs to be a discussion on how to best deal with cases where implementations have shipped to users with these glitches in them. I think it might be better to document them, so that client coders can implement work arounds (I am doing so for the three cases I've found) instead of the server being patched to change its behaviour, causing potentially more interoperability issues. (That's why I re-posted this to 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? Well, for a POSIX draft style client, the only effect is that a client may be broken (not handle the sr_eof == true reply correctly) without the implementors knowing that, since they tested against the Linux server. (I believe this is the current status of the Linux client.) For a server implementor (I get to wear both hats;-), the server can only generate one reply or the other. I've implemented both with a tunable that can be used to flip between them. I default to the NFS4ERR_NXIO reply, since that is what the Linux client expects. As for the Copy issues, the client can easily handle them, but the client coder needs to know about them. At this time the FreeBSD server code only implements what is in the RFC. This seems sufficient for the testing I've done sofar. The case that I think will break would be Linux code that does a copy_file_range(infd, NULL, outfd, NULL, INT_MAX, 0) to copy an entire file. I'll test this case to-day, but I'm think it will just get a NFS4ERR_INVAL reply from the FreeBSD server. (I can make this work for the Linux client, but it will take another "cheat" enabled via a tunable.) --> Part of the confusion here comes from the fact that the Linux syscall semantics for copy_file_range() has changed. (I also where the copy_file_range(2) hat for FreeBSD, so I've got some work to do there, too.) In summary, I think that, since Linux has been shipping this for some time, documenting workarounds is a practical approach. rick
