On Wed, Mar 16, 2016 at 3:56 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Wed, Mar 16, 2016 at 03:46:28PM -0400, Benjamin Coddington wrote: >> So, sounds like fixing this is a good idea on the server. I hope Trond will >> let us know if he still feels that the client ought not to be changed since >> it seems an easy enough fix to avoid a similar problem on another server. >> Perhaps there's a downside I'm not seeing on the client. > > My worry would just be ensuring forward progress--if the client gets > some data back, then at least the next read can start at a later > offset.... With zero reads, we can set a maximum number of retries, I > guess, but that makes it little messy. > >> Or maybe the >> convention of read() returning 0 meaning eof is global enough to cause it to >> be acceptible behavior -- we really should treat a zero-length read response >> without eof as an error. My lack of experience is showing.. :) > > Eh, I think it's legitimately more confusing than it should be. > POSIX is very specific about the cases where you are allowed to return a short read: See http://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html "The value returned may be less than nbyte if the number of bytes left in the file is less than nbyte, if the read() request was interrupted by a signal, or if the file is a pipe or FIFO or special file and has fewer than nbyte bytes immediately available for reading. For example, a read() from a file associated with a terminal may return one typed line of data." So I'm guessing most POSIX based server implementations should have no trouble working out exactly when to set the eof flag. However the client has no clue as to what OS your server is based on, which is presumably the main reason why NFS has an eof flag in the first place. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
