Linux NFS development
 help / color / mirror / Atom feed
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>

  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