From: Christoph Hellwig <hch@lst.de>
To: daejun7.park@samsung.com
Cc: Carlos Maiolino <cem@kernel.org>,
linux-xfs@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
"Darrick J. Wong" <djwong@kernel.org>,
Dave Chinner <dgc@kernel.org>,
Pankaj Raghav <p.raghav@samsung.com>,
Chuck Lever <cel@kernel.org>, Jeff Layton <jlayton@kernel.org>,
Dai Ngo <Dai.Ngo@oracle.com>,
Sergey Bashirov <sergeybashirov@gmail.com>,
Andrey Albershteyn <aalbersh@kernel.org>,
linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v5 5/9] xfs: cap the block count of xfs_iomap_write_direct() at one extent
Date: Tue, 3 Nov 2026 06:49:22 +0100 [thread overview]
Message-ID: <20261103054922.GA1721@lst.de> (raw)
In-Reply-To: <20261029-xfs-pnfs-batch-v5-5-ef8d2eafb7fa@samsung.com>
On Thu, Oct 29, 2026 at 11:23:02AM +0900, Daejun Park via B4 Relay wrote:
> From: Daejun Park <daejun7.park@samsung.com>
>
> xfs_iomap_write_direct() reserves blocks for the whole count in an
> unsigned int. For a pNFS layout the client chooses that count, and an
> RW LAYOUTGET for 16 TiB wraps the reservation and shuts XFS down.
>
> xfs_bmapi_write() maps at most XFS_MAX_BMBT_EXTLEN blocks here, so cap
> the count at that. nfsd asks again for the rest. The other callers get
> the same mapping as before.
>
> Suggested-by: Darrick J. Wong <djwong@kernel.org>
> Link: https://lore.kernel.org/r/20261008154017.GO2705364@frogsfrogsfrogs
> Suggested-by: Christoph Hellwig <hch@lst.de>
> Link: https://lore.kernel.org/r/20261015060932.GD14035@lst.de
> Suggested-by: Pankaj Raghav <p.raghav@samsung.com>
> Link: https://lore.kernel.org/r/atoImJxtg70XcIjS@quentin
I think this is overdoing it a bit with the Link tags.
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
next prev parent reply other threads:[~2026-11-03 5:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 2:22 [PATCH v5 0/9] xfs: pNFS block layout fixes Daejun Park via B4 Relay
2026-10-29 2:22 ` Daejun Park
2026-10-29 2:22 ` [PATCH v5 1/9] xfs: mark the inode preallocated for pNFS write layouts past EOF Daejun Park via B4 Relay
2026-10-29 2:22 ` Daejun Park
2026-10-29 2:22 ` [PATCH v5 2/9] xfs: add a flag to convert unwritten extents without allocating blocks Daejun Park via B4 Relay
2026-10-29 2:22 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 3/9] xfs: refuse a pNFS LAYOUTCOMMIT of a range without blocks Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 4/9] xfs: clamp a pNFS LAYOUTCOMMIT extent before computing its end Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 5/9] xfs: cap the block count of xfs_iomap_write_direct() at one extent Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-11-03 5:49 ` Christoph Hellwig [this message]
2026-11-03 8:44 ` Carlos Maiolino
2026-11-03 12:46 ` Pankaj Raghav (Samsung)
2026-10-29 2:23 ` [PATCH v5 6/9] xfs: clamp the pNFS layout range to the maximum file size Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 7/9] xfs: take the invalidate lock while mapping a pNFS layout Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 8/9] xfs: add datasync and log_flushed arguments to xfs_log_force_inode() Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-10-29 2:23 ` [PATCH v5 9/9] xfs: make pNFS LAYOUTCOMMIT stable the way fdatasync does Daejun Park via B4 Relay
2026-10-29 2:23 ` Daejun Park
2026-11-03 10:02 ` [PATCH v5 0/9] xfs: pNFS block layout fixes Carlos Maiolino
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=20261103054922.GA1721@lst.de \
--to=hch@lst.de \
--cc=Dai.Ngo@oracle.com \
--cc=aalbersh@kernel.org \
--cc=cel@kernel.org \
--cc=cem@kernel.org \
--cc=daejun7.park@samsung.com \
--cc=dgc@kernel.org \
--cc=djwong@kernel.org \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=p.raghav@samsung.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.