Linux NFS development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox