From: Daejun Park <daejun7.park@samsung.com>
To: "Darrick J. Wong" <djwong@kernel.org>
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>,
Daejun Park <daejun7.park@samsung.com>
Subject: RE:(2) [PATCH] xfs: map pNFS layouts to the end of the extent again
Date: Tue, 06 Oct 2026 14:48:46 +0900 [thread overview]
Message-ID: <20261006054846epcms2p8ebfcaa89742030bfc07a7d1bb5ee3dfb@epcms2p8> (raw)
In-Reply-To: <20261006051324.GV2705364@frogsfrogsfrogs>
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.
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.
next prev parent reply other threads:[~2026-10-06 5:48 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 [this message]
2026-10-06 15:23 ` (2) " Darrick J. Wong
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=20261006054846epcms2p8ebfcaa89742030bfc07a7d1bb5ee3dfb@epcms2p8 \
--to=daejun7.park@samsung.com \
--cc=cel@kernel.org \
--cc=cem@kernel.org \
--cc=dai.ngo@oracle.com \
--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 \
/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®