From: "Anna Schumaker" <anna@kernel.org>
To: "Benjamin Coddington" <ben.coddington@hammerspace.com>,
"Trond Myklebust" <trondmy@kernel.org>
Cc: linux-nfs@vger.kernel.org,
"Jonathan Curley" <jcurley@purestorage.com>,
"Mike Snitzer" <snitzer@kernel.org>,
"Jeff Layton" <jlayton@kernel.org>
Subject: Re: [PATCH v2 1/6] NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET
Date: Tue, 08 Sep 2026 13:35:10 -0400 [thread overview]
Message-ID: <15ea408a-5e87-4a65-ac94-10e357683a8d@app.fastmail.com> (raw)
In-Reply-To: <a906e6ed5bd3fd560ace313a6b64491e1da835ab.1788453839.git.bcodding@hammerspace.com>
Hi Ben,
On Fri, Sep 4, 2026, at 8:56 AM, Benjamin Coddington wrote:
> If the layout for the requested range is larger than the size the
> client advertised in loga_maxcount, RFC 8881 Section 18.43.3 has the
> metadata server return NFS4ERR_TOOSMALL. The client caps
> loga_maxcount at a single page, so a flexfiles server that stripes a
> layout segment across several dozen data servers produces this error
> today.
>
> The client has no handling for it: nfs4_stat_to_errno() maps the
> error to -ETOOSMALL during decode, which nothing in the layoutget
> path recognizes and nfs_error_is_fatal() does not consider fatal, so
> pnfs_update_layout() clears the layout fail bit and returns no
> segment. The I/O falls back to the MDS, but because no fail bit was
> set, every subsequent pageio attempt sends another LAYOUTGET that is
> doomed to the same NFS4ERR_TOOSMALL. Files whose layouts do not fit
> the reply buffer never use pNFS and pay an extra round trip on every
> pageio.
>
> Map -ETOOSMALL to -EMSGSIZE in the layoutget exception handler and
> have pnfs_update_layout() treat it like NFS4ERR_LAYOUTUNAVAILABLE:
> mark the layout mode as failed and fall back to I/O through the MDS.
>
> Fixes: d600ad1f2bdb ("NFS41: pop some layoutget errors to application")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Benjamin Coddington <bcodding@hammerspace.com>
> Reviewed-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/nfs/nfs4proc.c | 8 ++++++++
> fs/nfs/pnfs.c | 2 ++
> 2 files changed, 10 insertions(+)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 04b1987115d5..e41c792a2725 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -9680,6 +9680,14 @@ nfs4_layoutget_handle_exception(struct rpc_task *task,
> case -NFS4ERR_BADLAYOUT:
> status = -EOVERFLOW;
> goto out;
> + /*
> + * NFS4ERR_TOOSMALL means the layout for the requested range
> + * exceeds what the client advertised in loga_maxcount (see
> + * RFC8881 section 18.43.3).
> + */
> + case -ETOOSMALL:
Should this be NFS4ERR_TOOSMALL instead of ETOOSMALL?
Thanks,
Anna
> + status = -EMSGSIZE;
> + goto out;
> /*
> * NFS4ERR_LAYOUTTRYLATER is a conflict with another client
> * (or clients) writing to the same RAID stripe except when
> diff --git a/fs/nfs/pnfs.c b/fs/nfs/pnfs.c
> index 4f9c0f639014..c5d1951d5400 100644
> --- a/fs/nfs/pnfs.c
> +++ b/fs/nfs/pnfs.c
> @@ -2331,6 +2331,8 @@ pnfs_update_layout(struct inode *ino,
> break;
> case -ENODATA:
> /* The server returned NFS4ERR_LAYOUTUNAVAILABLE */
> + case -EMSGSIZE:
> + /* The layout exceeded loga_maxcount (NFS4ERR_TOOSMALL) */
> pnfs_layout_set_fail_bit(
> lo, pnfs_iomode_to_fail_bit(iomode));
> lseg = NULL;
> --
> 2.53.0
next prev parent reply other threads:[~2026-09-08 17:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 12:56 [PATCH v2 0/6] NFS: size the LAYOUTGET reply buffer for wide flexfiles layouts Benjamin Coddington
2026-09-04 12:56 ` [PATCH v2 1/6] NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET Benjamin Coddington
2026-09-08 17:35 ` Anna Schumaker [this message]
2026-09-08 18:58 ` Benjamin Coddington
2026-09-08 20:06 ` Anna Schumaker
2026-09-04 12:56 ` [PATCH v2 2/6] NFSv4.1/pnfs: derive loga_maxcount from the LAYOUTGET reply buffer Benjamin Coddington
2026-09-04 12:56 ` [PATCH v2 3/6] NFSv4.1/pnfs: retry LAYOUTGET with a larger reply buffer on NFS4ERR_TOOSMALL Benjamin Coddington
2026-09-04 12:56 ` [PATCH v2 4/6] NFSv4.1/pnfs: treat an oversized LAYOUTGET reply as -EMSGSIZE Benjamin Coddington
2026-09-04 12:56 ` [PATCH v2 5/6] NFSv4.1/pnfs: remember when a server needs a larger LAYOUTGET reply buffer Benjamin Coddington
2026-09-04 12:56 ` [PATCH v2 6/6] NFSv4/flexfiles: allocate the per-mirror stripe array with kvzalloc_objs Benjamin Coddington
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=15ea408a-5e87-4a65-ac94-10e357683a8d@app.fastmail.com \
--to=anna@kernel.org \
--cc=ben.coddington@hammerspace.com \
--cc=jcurley@purestorage.com \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=snitzer@kernel.org \
--cc=trondmy@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