mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chuck Lever" <cel@kernel.org>
To: "Daejun Park" <daejun7.park@samsung.com>
Cc: "Jeff Layton" <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
	"Olga Kornievskaia" <okorniev@redhat.com>,
	"Dai Ngo" <Dai.Ngo@oracle.com>, "Tom Talpey" <tom@talpey.com>,
	"Christoph Hellwig" <hch@lst.de>,
	"Carlos Maiolino" <cem@kernel.org>,
	"Amir Goldstein" <amir73il@gmail.com>,
	"Darrick J. Wong" <djwong@kernel.org>,
	"Dave Chinner" <dgc@kernel.org>,
	"Sergey Bashirov" <sergeybashirov@gmail.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: (2) [PATCH 7/8] xfs: map the whole range of a pNFS layout in one ->map_blocks call
Date: Mon, 12 Oct 2026 10:26:12 -0400	[thread overview]
Message-ID: <b31fd2ce-3b1f-4cf5-9af9-70ea89a4d67c@app.fastmail.com> (raw)
In-Reply-To: <20261012024846epcms2p7cccc5c988b2553b3f831070eb17e0455@epcms2p7>



On Sun, Oct 11, 2026, at 10:48 PM, Daejun Park wrote:
> On Thu, Oct 08, 2026 at 12:37:46PM -0400, Chuck Lever wrote:
>> The same freeing can happen to blocks a client holds a write layout
>> for, AFAICS. But that is not new. Commit 527851124d10 handed out the
>> same blocks.
>>
>> This is however the patch where a fix could go.
>
> Yes. xfs_fs_map_blocks() marks the inode XFS_DIFLAG_PREALLOC only when
> it allocates, so a write layout past EOF over blocks that buffered
> writes preallocated leaves the inode unmarked, and blockgc frees those
> blocks while the client holds them.
>
> With pynfs as the client on nfsd-testing: a file grown to 1 MiB by two
> buffered writes on the server had 960 KiB preallocated past EOF, and an
> RW LAYOUTGET for that range got it as one INVALID_DATA extent, without
> the inode being marked. About 300 seconds later, with the default
> speculative_prealloc_lifetime, blockgc freed the 960 KiB while the
> layout was still held. Small files written on the server after that, and
> after a sync so that the freed extents were no longer busy, got those
> blocks, and the client's write through the layout replaced 978944 bytes
> of their data. The LAYOUTCOMMIT then got NFS4ERR_IO, as
> xfs_iomap_write_unwritten() allocated for the hole with no blocks
> reserved, and XFS shut down with "Corruption of in-memory data (0x8)
> detected at xfs_trans_mod_sb", in six runs out of six. Committing 30
> seconds after the LAYOUTGET, before blockgc, works.
>
> I would rather fix it on its own, before the series, so that it can go
> to stable: mark the inode as preallocated also when a write mapping
> ends past EOF and nothing was allocated. With that, the same test keeps
> the blocks and the LAYOUTCOMMIT succeeds. I will send it to the XFS
> list, and patch 7 of v2 will keep the check for the mappings of the
> whole call.

Sensible, thanks.

-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)

  reply	other threads:[~2026-10-12 14:26 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08  1:39 [PATCH 0/8] xfs, nfsd: map a whole pNFS block " Daejun Park via B4 Relay
2026-10-08  1:39 ` [PATCH 1/8] xfs: map pNFS layouts to the end of the extent again Daejun Park via B4 Relay
2026-10-08  1:39 ` [PATCH 2/8] xfs: refuse a direct allocation whose block reservation would wrap Daejun Park via B4 Relay
2026-10-08 15:40   ` Darrick J. Wong
     [not found]   ` <CGME20261008154023epcas2p487b78abba35fdc6d75f9dd8d62a39837@epcms2p1>
2026-10-12  2:47     ` Daejun Park
2026-10-08  1:39 ` [PATCH 3/8] xfs: clamp the pNFS layout range to the maximum file size Daejun Park via B4 Relay
2026-10-08 15:41   ` Darrick J. Wong
2026-10-08  1:39 ` [PATCH 4/8] exportfs: let ->map_blocks return more than one mapping Daejun Park via B4 Relay
2026-10-08  1:39 ` [PATCH 5/8] xfs: factor the mapping of one pNFS extent out of xfs_fs_map_blocks() Daejun Park via B4 Relay
2026-10-08  1:39 ` [PATCH 6/8] xfs: take the invalidate lock while mapping a pNFS layout Daejun Park via B4 Relay
2026-10-08  1:39 ` [PATCH 7/8] xfs: map the whole range of a pNFS layout in one ->map_blocks call Daejun Park via B4 Relay
2026-10-08 16:37   ` Chuck Lever
     [not found]   ` <CGME20261008163812epcas2p120bb86754876aa75cd744bd63258c465@epcms2p7>
2026-10-12  2:48     ` Daejun Park
2026-10-12 14:26       ` Chuck Lever [this message]
2026-10-08  1:39 ` [PATCH 8/8] nfsd: get all extents of a block " Daejun Park via B4 Relay
2026-10-08 16:44   ` Chuck Lever
     [not found]   ` <CGME20261008164459epcas2p313b027cb2807a94a05edb388633152ed@epcms2p1>
2026-10-12  2:49     ` 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=b31fd2ce-3b1f-4cf5-9af9-70ea89a4d67c@app.fastmail.com \
    --to=cel@kernel.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=daejun7.park@samsung.com \
    --cc=dgc@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=sergeybashirov@gmail.com \
    --cc=tom@talpey.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

all inboxes | Powered by JetHome®