On Thu, Oct 17, 2019 at 12:20 PM Rick Macklem <rmacklem@xxxxxxxxxxx> wrote: > > 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. this might be problematic for the linux client because though there isn't an official use of it but the libc cp might implement this doing exactly what you say here copy_file_range(infd, NULL, outfd, NULL, INT_MAX, 0). It doesn't try to determine the size of the file before the copy and just copy max bytes assuming that it'll get a short read at some point. > (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 > > _______________________________________________ > nfsv4 mailing list > nfsv4@xxxxxxxx > https://www.ietf.org/mailman/listinfo/nfsv4
