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

  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