From: Benjamin Coddington <ben.coddington@hammerspace.com>
To: Trond Myklebust <trondmy@kernel.org>, Anna Schumaker <anna@kernel.org>
Cc: linux-nfs@vger.kernel.org, Daejun Park <daejun7.park@samsung.com>,
Christoph Hellwig <hch@lst.de>
Subject: [PATCH v2 0/2] pnfs/blocklayout: report LAYOUTCOMMIT failures
Date: Mon, 26 Oct 2026 19:27:47 -0400 [thread overview]
Message-ID: <cover.1792157092.git.bcodding@hammerspace.com> (raw)
From: Benjamin Coddington <bcodding@hammerspace.com>
Data a block or SCSI layout client writes into unwritten extents becomes
file data only when a LAYOUTCOMMIT succeeds. A server that has revoked
the layout answers NFS4ERR_BADLAYOUT, nfs4_layoutcommit_done() ignores
it, and fsync() and close() return 0 for data that reads back as
zeroes. nfsd reaches this through its recall failure path today, and
the layout recall series [1] makes it more likely.
Patch 1 keeps the extents uncommitted when the LAYOUTCOMMIT fails before
its result is decoded. Patch 2 records a writeback error when extents go
uncommitted and returns it from the block/SCSI ->sync. The files and
flexfiles layouts are unchanged.
NB: these are compile-tested only; I don't have a setup handy that can
revoke the layout..
Changes since v1:
- Patch 2: replace pnfs_generic_sync() with bl_sync() in the block
layout driver (Christoph).
- Patch 2: check the raw wb_err value instead of a sample, so ->sync
from inode revalidation no longer returns an older unseen writeback
error from every stat() (sashiko).
v1: https://lore.kernel.org/linux-nfs/cover.1792097970.git.bcodding@hammerspace.com/
[1] https://lore.kernel.org/linux-nfs/20261015-nfsd-layout-recall-v3-0-ba3269f8ca22@samsung.com/
Benjamin Coddington (2):
pnfs/blocklayout: don't mark extents committed after a failed
LAYOUTCOMMIT
pnfs/blocklayout: report data lost to a failed LAYOUTCOMMIT
fs/nfs/blocklayout/blocklayout.c | 20 +++++++++++++++++---
fs/nfs/blocklayout/extent_tree.c | 14 +++++++++++---
fs/nfs/pnfs.c | 7 -------
fs/nfs/pnfs.h | 1 -
4 files changed, 28 insertions(+), 14 deletions(-)
base-commit: a90ee4305c4a5df72c11b31dacfdc76e00fcf78a
--
2.53.0
next reply other threads:[~2026-10-26 23:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-26 23:27 Benjamin Coddington [this message]
2026-10-26 23:27 ` [PATCH v2 1/2] pnfs/blocklayout: don't mark extents committed after a failed LAYOUTCOMMIT Benjamin Coddington
2026-10-28 16:18 ` Christoph Hellwig
2026-10-29 6:44 ` Daejun Park
2026-10-26 23:27 ` [PATCH v2 2/2] pnfs/blocklayout: report data lost to " Benjamin Coddington
2026-10-28 16:18 ` Christoph Hellwig
2026-10-29 6:45 ` Daejun Park
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=cover.1792157092.git.bcodding@hammerspace.com \
--to=ben.coddington@hammerspace.com \
--cc=anna@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=hch@lst.de \
--cc=linux-nfs@vger.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