All of lore.kernel.org
 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 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.