From: Jeff Layton <jlayton@kernel.org>
To: Benjamin Coddington <ben.coddington@hammerspace.com>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org,
Jonathan Curley <jcurley@purestorage.com>,
Mike Snitzer <snitzer@kernel.org>
Subject: Re: [PATCH 1/6] NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET
Date: Fri, 14 Aug 2026 10:19:10 -0400 [thread overview]
Message-ID: <0386c7cf81b5028b790e5dc6962b69a31d745ffc.camel@kernel.org> (raw)
In-Reply-To: <57c201555a87e999cd2de1747901f3b6cc3d5792.1786653456.git.bcodding@hammerspace.com>
On Thu, 2026-08-13 at 16:41 -0400, 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>
> ---
> fs/nfs/nfs4proc.c | 9 +++++++++
> fs/nfs/pnfs.c | 2 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 5709c6fea85b..016e8b38b87b 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -9623,6 +9623,15 @@ 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). Note nfs4_stat_to_errno() has
> + * already mapped it to -ETOOSMALL during decode.
> + */
nit: LLMs sure love to generate some overly-wordy comments. I think the
last sentence here is not particularly helpful, and subject to bitrot
as the code changes over time. I'd just drop it.
> + case -ETOOSMALL:
> + 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 7715e2bd5871..10102bda6a38 100644
> --- a/fs/nfs/pnfs.c
> +++ b/fs/nfs/pnfs.c
> @@ -2338,6 +2338,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;
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-08-14 14:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 20:41 [PATCH 0/6] NFS: size the LAYOUTGET reply buffer for wide flexfiles layouts Benjamin Coddington
2026-08-13 20:41 ` [PATCH 1/6] NFSv4.1/pnfs: suspend pNFS on NFS4ERR_TOOSMALL from LAYOUTGET Benjamin Coddington
2026-08-14 14:19 ` Jeff Layton [this message]
2026-08-13 20:41 ` [PATCH 2/6] NFSv4.1/pnfs: derive loga_maxcount from the LAYOUTGET reply buffer Benjamin Coddington
2026-08-13 20:41 ` [PATCH 3/6] NFSv4.1/pnfs: retry LAYOUTGET with a larger reply buffer on NFS4ERR_TOOSMALL Benjamin Coddington
2026-08-13 20:41 ` [PATCH 4/6] NFSv4.1/pnfs: treat an oversized LAYOUTGET reply as -EMSGSIZE Benjamin Coddington
2026-08-13 20:41 ` [PATCH 5/6] NFSv4.1/pnfs: remember when a server needs a larger LAYOUTGET reply buffer Benjamin Coddington
2026-08-13 20:41 ` [PATCH 6/6] NFSv4/flexfiles: allocate the per-mirror stripe array with kvzalloc_objs Benjamin Coddington
2026-08-14 15:39 ` [PATCH 0/6] NFS: size the LAYOUTGET reply buffer for wide flexfiles layouts Jeff Layton
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=0386c7cf81b5028b790e5dc6962b69a31d745ffc.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=anna@kernel.org \
--cc=ben.coddington@hammerspace.com \
--cc=jcurley@purestorage.com \
--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