RE:(2) [PATCH 8/8] nfsd: get all extents of a block layout in one ->map_blocks call

[Daejun Park]

On Thu, Oct 08, 2026 at 12:44:33PM -0400, Chuck Lever wrote:
> nr_extents_max is bounded by PAGE_SIZE so that the per-request buffer
> stays small. But a struct iomap is nearly twice the size of an encoded
> extent, so this array is nearly twice the layout buffer it sits next
> to. On 64 KiB pages that is well over 100 KiB of physically contiguous
> memory per LAYOUTGET. A failure here turns into NFS4ERR_DELAY for
> every request under fragmentation.
>
> Using kvmalloc_array() would cover the large case, or you could cap
> nr_extents_max independently of PAGE_SIZE.

I will use kvmalloc_array() in v2.

> Passing write only when loga_minlength is non-zero, and having
> nfsd4_block_iomap_to_extent() refuse IOMAP_HOLE for IOMODE_RW the way
> it already refuses IOMAP_UNWRITTEN, gives the client the same answer
> without allocating anything. Admittedly this is a pre-existing
> issue -- perhaps a pre-requisite fix for this series is best, so
> that the fix can be backported to LTS.

Agreed, I will post it against nfsd-testing as a separate patch. It goes
back to commit 8c3ad9cb7343 ("nfsd/blocklayout: accept any minlength"),
which removed the check that refused a minlength below the block size.
With pynfs as the client on nfsd-testing, an RW LAYOUTGET for 0+1 MiB
with a minlength of zero on an empty file got NFS4ERR_LAYOUTUNAVAILABLE
and left 1 MiB allocated. With the change you describe it gets the same
error and nothing is allocated, and one for 64 KiB of written data is
still granted as READ_WRITE_DATA. v2 of this patch will take the same
change.

> A note about process: the series touches XFS and exportfs. It will
> need to go through the VFS tree, I think, and might conflict with
> what's already in nfsd-testing.

Patch 1 is now in xfs for-next (e3c682dd1130), and patch 8 builds on
170b788af22d in nfsd-testing, so patches 4 to 8 depend on both trees.
I will post them again after the merge window, rebased on -rc1, for the
VFS tree. Patches 2 and 3 are XFS fixes on their own and apply to xfs
for-next as they are, so they can go through the XFS tree before that
if Carlos wants them.