Linux NFS development
 help / color / mirror / Atom feed
From: Trond Myklebust <trondmy@kernel.org>
To: tmenninger@purestorage.com, Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
	 stable@vger.kernel.org
Subject: Re: [PATCH] pNFS: Check lseg validity before marking a layout for return
Date: Tue, 18 Aug 2026 10:57:05 -0700	[thread overview]
Message-ID: <ee96bac85fec2cf59adfb3d4ff54182c8260f6cb.camel@kernel.org> (raw)
In-Reply-To: <20260813135834.22278-1-tmenninger@purestorage.com>

On Thu, 2026-08-13 at 13:58 +0000, tmenninger@purestorage.com wrote:
> From: Tim Menninger <tmenninger@purestorage.com>
> 
> pnfs_error_mark_layout_for_return() receives the lseg associated with
> the failed I/O but previously used only its I/O mode, operating on
> the
> inode's current layout header regardless of whether the lseg itself
> was
> still valid.
> 
> A layout stateid can be invalidated while RPCs still hold references
> to
> its lsegs. pnfs_mark_layout_stateid_invalid() clears NFS_LSEG_VALID
> on
> those lsegs through pnfs_clear_lseg_state(). A subsequent LAYOUTGET
> can
> install a replacement stateid in the same pnfs_layout_hdr. If an RPC
> using one of the old lsegs later reports an error, the current code
> can
> therefore mark the replacement layout for return.
> 
> Once NFS_LSEG_VALID has been cleared, the lseg is no longer eligible
> for
> selection for new I/O and must not initiate another error-driven
> return
> of the inode's current layout. Fold pnfs_mark_layout_for_return()

I strongly disagree with the above premise that NFS_LSEG_VALID should
be used to gate layout returns. If the client tries to do I/O and
fails, then it is required to report the error, the type of I/O, and
the byte range to which it applies.
We attempt to redrive that layoutreturn as the outstanding I/O requests
fail. The EBUSY is there to ensure that we don't fire off the
layoutreturn until all the errors have been collected.


So NACK to this patch.
-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com

      reply	other threads:[~2026-08-18 17:57 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13 13:58 [PATCH] pNFS: Check lseg validity before marking a layout for return tmenninger
2026-08-18 17:57 ` Trond Myklebust [this message]

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=ee96bac85fec2cf59adfb3d4ff54182c8260f6cb.camel@kernel.org \
    --to=trondmy@kernel.org \
    --cc=anna@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tmenninger@purestorage.com \
    /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