All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Aloni <dan.aloni@vastdata.com>
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Anna Schumaker <Anna.Schumaker@netapp.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH v2] NFSD: trim reads past NFS_OFFSET_MAX and fix NFSv3 check
Date: Sun, 23 Jan 2022 08:29:19 +0200	[thread overview]
Message-ID: <20220123062919.7yjz5ryousix6vxf@gmail.com> (raw)
In-Reply-To: <ADEC85C2-8D72-4E25-A49B-2039C1FF82F2@oracle.com>

On Sat, Jan 22, 2022 at 05:37:16PM +0000, Chuck Lever III wrote:
> Similar language in RFC 8881 section 18.22.4:
> 
> >>    If the server returns a "short read" (i.e., fewer data than requested
> >>    and eof is set to FALSE), the client should send another READ to get
> >>    the remaining data.  A server may return less data than requested
> >>    under several circumstances.  The file may have been truncated by
> >>    another client or perhaps on the server itself, changing the file
> >>    size from what the requesting client believes to be the case.  This
> >>    would reduce the actual amount of data available to the client.  It
> >>    is possible that the server reduce the transfer size and so return a
> >>    short read result.  Server resource exhaustion may also occur in a
> >>    short read.
> 
> So the server could be returning INVAL and leaving EOF set
> to false. That might be triggering the client to retry the
> READ. Does the server need to set the EOF flag if the READ
> arguments cross the limit of the range that the server can
> return? Does the client need to check for this case and
> stop retrying? The specs aren't particularly clear on this
> matter.

But eof only in `resok` and not in `resfail`. For reference, here's the
reply I got:

Network File System, READ Reply  Error: NFS3ERR_INVAL
    [Program Version: 3]
    [V3 Procedure: READ (6)]
    Status: NFS3ERR_INVAL (22)
    file_attributes  Regular File mode: 0600 uid: 0 gid: 0
        attributes_follow: value follows (1)
        attributes  Regular File mode: 0600 uid: 0 gid: 0
            Type: Regular File (1)
            Mode: 0600, S_IRUSR, S_IWUSR
            nlink: 1
            uid: 0
            gid: 0
            size: 9223372036854775807
            used: 4096
            rdev: 0,0
            fsid: 0x0000000000000002 (2)
            fileid: 69
            atime: Jan 18, 2022 20:20:33.611267439 IST
                seconds: 1642530033
                nano seconds: 611267439
            mtime: Jan 18, 2022 20:20:33.571266608 IST
                seconds: 1642530033
                nano seconds: 571266608
            ctime: Jan 18, 2022 20:20:33.571266608 IST
                seconds: 1642530033
                nano seconds: 571266608

-- 
Dan Aloni

  reply	other threads:[~2022-01-23  6:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-27 18:00 [PATCH] NFS: Always provide aligned buffers to the RPC read layers trondmy
2022-01-18 19:26 ` Dan Aloni
2022-01-18 19:33   ` [PATCH] NFS: fix an infinite request retry in an off-by-one last page read Dan Aloni
2022-01-18 19:43     ` Trond Myklebust
2022-01-21 18:50       ` [PATCH] NFSD: trim reads past NFS_OFFSET_MAX Dan Aloni
2022-01-21 22:32         ` Chuck Lever III
2022-01-22 12:47           ` Dan Aloni
2022-01-22 17:05             ` Chuck Lever III
2022-01-22 18:27               ` Trond Myklebust
2022-01-22 20:15                 ` Chuck Lever III
2022-01-22 20:30                   ` Trond Myklebust
2022-01-23 17:35                     ` Chuck Lever III
2022-01-22 19:01               ` Dan Aloni
2022-01-22 20:33                 ` Chuck Lever III
2022-01-22 12:49           ` [PATCH v2] NFSD: trim reads past NFS_OFFSET_MAX and fix NFSv3 check Dan Aloni
2022-01-22 17:37             ` Chuck Lever III
2022-01-23  6:29               ` Dan Aloni [this message]
2022-01-23  9:50               ` [PATCH v3] " Dan Aloni
2022-01-23 15:29                 ` Trond Myklebust
2022-01-23 17:03                   ` Chuck Lever III
2022-01-26 16:23                     ` Chuck Lever III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220123062919.7yjz5ryousix6vxf@gmail.com \
    --to=dan.aloni@vastdata.com \
    --cc=Anna.Schumaker@netapp.com \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.