From: "Darrick J. Wong" <djwong@kernel.org>
To: Daejun Park <daejun7.park@samsung.com>
Cc: "cem@kernel.org" <cem@kernel.org>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>,
"dai.ngo@oracle.com" <dai.ngo@oracle.com>,
"hch@lst.de" <hch@lst.de>, "dgc@kernel.org" <dgc@kernel.org>,
"sergeybashirov@gmail.com" <sergeybashirov@gmail.com>,
"cel@kernel.org" <cel@kernel.org>,
"jlayton@kernel.org" <jlayton@kernel.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: (2) [PATCH] xfs: map pNFS layouts to the end of the extent again
Date: Tue, 6 Oct 2026 08:23:33 -0700 [thread overview]
Message-ID: <20261006152333.GO1615495@frogsfrogsfrogs> (raw)
In-Reply-To: <20261006054846epcms2p8ebfcaa89742030bfc07a7d1bb5ee3dfb@epcms2p8>
On Tue, Oct 06, 2026 at 02:48:46PM +0900, Daejun Park wrote:
> On Mon, Oct 05, 2026 at 10:13:24PM -0700, Darrick J. Wong wrote:
> > I wonder, though, should the caller (i.e. NFS) do this trimming to
> > protect itself from other filesystems making the same mistake?
>
> I agree that nfsd needs a patch as well. nfsd4_block_proc_layoutget()
> could trim every extent after the first to start at the offset asked
> for, moving soff by the same amount for the written and unwritten ones.
> If that sounds right, I can send a patch for it.
Hmm. You're right that only the filesystem knows where the upper end of
the mapping should be. So either nfsd limits itself to trimming the
lower end (because we know that we need a mapping for at least one block
starting at @offset) or we just WARN_ON in that case and return EIO or
something?
> This patch still makes sense as it is. Mapping to the end of the extent
> can only be done in XFS, and with the trim in XFS as well, the stable
> fix does not depend on the nfsd patch. What the trim costs shows in the
> 4 KiB random row of the table: 15 LAYOUTGETs instead of 1, with no
> clear change in I/Os done.
<nod> I'm satisfied with the xfs part, so
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
--D
prev parent reply other threads:[~2026-10-06 15:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20261006003425epcms2p586728e55ff5f9bbabc506b672fc4a421@epcms2p5>
2026-10-06 0:34 ` Daejun Park
2026-10-06 5:13 ` Darrick J. Wong
[not found] ` <CGME20261006003425epcms2p586728e55ff5f9bbabc506b672fc4a421@epcms2p8>
2026-10-06 5:48 ` Daejun Park
2026-10-06 15:23 ` Darrick J. Wong [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=20261006152333.GO1615495@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=cel@kernel.org \
--cc=cem@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=dai.ngo@oracle.com \
--cc=dgc@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 \
/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®