From: Daejun Park <daejun7.park@samsung.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Carlos Maiolino <cem@kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"Darrick J. Wong" <djwong@kernel.org>,
Dave Chinner <dgc@kernel.org>, Chuck Lever <cel@kernel.org>,
Jeff Layton <jlayton@kernel.org>, Dai Ngo <Dai.Ngo@oracle.com>,
Sergey Bashirov <sergeybashirov@gmail.com>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
Daejun Park <daejun7.park@samsung.com>
Subject: RE:(2) [PATCH] xfs: mark the inode preallocated for pNFS write layouts past EOF
Date: Tue, 13 Oct 2026 10:31:59 +0900 [thread overview]
Message-ID: <20261013013159epcms2p3fea98953ac15bf1c1505057e5cd2c5ba@epcms2p3> (raw)
In-Reply-To: <20261012124118.GB32488@lst.de>
On Mon, Oct 12, 2026 at 02:41:18PM +0200, Christoph Hellwig wrote:
> > + if (write && !(ip->i_diflags & XFS_DIFLAG_PREALLOC) &&
> > + imap.br_startoff + imap.br_blockcount >
> > + XFS_B_TO_FSB(mp, XFS_ISIZE(ip))) {
> > + error = xfs_fs_map_update_inode(ip);
> > + if (!error)
> > + error = xfs_log_force_inode(ip);
> > + if (error)
> > + goto out_unlock;
> > + }
>
> Let's avoid the code duplication here. Add a boolean flag that
> we need the update, set it both for the new allocation in the if
> le, and based on the condition here, and then do the update
> in a separate conditional below.
>
> And mayne the xfs_log_force_inode should move into
> xfs_fs_map_update_inode while we're at it.
Will do both in v2. xfs_fs_map_blocks() sets a flag for the allocation
and for a write mapping that ends past EOF over blocks that are already
there, and calls xfs_fs_map_update_inode() once after the if/else.
xfs_fs_map_update_inode() forces the log after committing the
transaction, so the separate xfs_log_force_inode() calls go away.
The behaviour does not change: the update still happens under the
IOLOCK, before the blocks are handed out. On nfsd-testing with the same
reproducer, the inode is marked at LAYOUTGET, blockgc keeps the blocks,
and the LAYOUTCOMMIT after 360 seconds succeeds with the data in place,
as with v1.
I will wait a few days for other comments on v1 and then send v2.
prev parent reply other threads:[~2026-10-13 1:32 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 3:04 Daejun Park via B4 Relay
2026-10-12 12:41 ` Christoph Hellwig
[not found] ` <CGME20261012124126epcas2p136e362cfd7a8ec3b16cca7d192565650@epcms2p3>
2026-10-13 1:31 ` Daejun Park [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=20261013013159epcms2p3fea98953ac15bf1c1505057e5cd2c5ba@epcms2p3 \
--to=daejun7.park@samsung.com \
--cc=Dai.Ngo@oracle.com \
--cc=cel@kernel.org \
--cc=cem@kernel.org \
--cc=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sergeybashirov@gmail.com \
--cc=stable@vger.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
all inboxes | Powered by JetHome®