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
next prev parent 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.