On Wed, Mar 16, 2016 at 10:22 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > On Wed, 16 Mar 2016, Trond Myklebust wrote: > >> On Wed, Mar 16, 2016 at 5:17 AM, Benjamin Coddington >> <bcodding@xxxxxxxxxx> wrote: >> > >> > A zero-length short read without eof should be retried rather than sending >> > an error to the application. >> >> >> In what situation would returning a 0 length read not be a bug? If the >> server intended that we back off and retry, it has the alternative of >> sending a JUKEBOX/DELAY error. > > If the server completes a local read but then another writer comes in and > appends to the file before the server checks if it needs to set EOF, then > the response might be 0 length without EOF set. Why isn't that EOF check done atomically with the read itself? This still sounds like a server bug to me. > I'm also using https://tools.ietf.org/html/rfc7530#section-16.23.5 to guide > how I think the client should behave; it says that the client should retry > a short read without eof set. I think that should include a response with > 0 length. >> > Signed-off-by: Benjamin Coddington <bcodding@xxxxxxxxxx> >> > --- >> > fs/nfs/read.c | 5 ----- >> > 1 files changed, 0 insertions(+), 5 deletions(-) >> > >> > diff --git a/fs/nfs/read.c b/fs/nfs/read.c >> > index eb31e23..7269d42 100644 >> > --- a/fs/nfs/read.c >> > +++ b/fs/nfs/read.c >> > @@ -244,11 +244,6 @@ static void nfs_readpage_retry(struct rpc_task *task, >> > >> > /* This is a short read! */ >> > nfs_inc_stats(hdr->inode, NFSIOS_SHORTREAD); >> > - /* Has the server at least made some progress? */ >> > - if (resp->count == 0) { >> > - nfs_set_pgio_error(hdr, -EIO, argp->offset); >> > - return; >> > - } >> > >> > /* For non rpc-based layout drivers, retry-through-MDS */ >> > if (!task->tk_ops) { >> > -- >> > 1.7.1 >> > >> -- 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
