Re: [PATCH 1/1] xfs: fix overlapping extents returned for pNFS LAYOUTGET

[Dai Ngo <dai.ngo@oracle.com>]

On 5/17/26 10:09 PM, Christoph Hellwig wrote:
> On Fri, May 15, 2026 at 07:14:29PM -0700, Dai Ngo wrote:
>> Currently the map_blocks() API between the NFS server and XFS does not
>> provide a way to specify whether XFS should use XFS_BMAPI_ENTIRE or '0'.
>> xfs_fs_map_blocks() just uses XFS_BMAPI_ENTIRE.
> And that is a good thing.
>
>> On the first mapping call, NFS server always specify the whole file
>> range that requested by the client in the LAYOUTGET.
>>
>> So if xfs_fs_map_blocks() can not return the requested mapping range
>> with '0' on the first mapping call then I think using XFS_BMAPI_ENTIRE
>> in the first mapping call makes any different.
> Yes.  Still not sure why we get a second call that overlaps with the
> first one in a single layoutget operation, though.

I added debug code to dump the mapping of the file before and after
NFSD calls to xfs_fs_map_blocks() completed:

May 18 18:03:59 dngo kernel: XFS (sdb): pNFS inode 3846447 iomap dump
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[28672] len[12288] addr[1957031936] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[73728] len[65536] addr[1957076992] type[2] flags[0x0] state[0]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[139264] len[4096] addr[1957142528] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[143360] len[16384] addr[1957146624] type[2] flags[0x0] state[0]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[159744] len[4096] addr[1957163008] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[163840] len[8192] addr[1957167104] type[2] flags[0x0] state[0]    /* type_2: IOMAP_MAPPED */
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[172032] len[12288] addr[1957175296] type[3] flags[0x0] state[1]   <<= entry# 7 & 8 will merge
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[188416] len[32768] addr[1957191680] type[3] flags[0x0] state[1]   <<= into entry# 7 below
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[258048] len[4096] addr[1957261312] type[3] flags[0x0] state[1]

May 18 18:03:59 dngo kernel: nfsd4_block_proc_layoutget: i[1] seg->offset[184320] seg->length[65536] seg->iomode[2] bex->foff[172032] offset[188416]
May 18 18:03:59 dngo kernel: Ext[0] foff[184320] len[4096] es[2] soff[1957187584]   /* es_2: PNFS_BLOCK_INVALID_DATA */
May 18 18:03:59 dngo kernel: Ext[1] foff[172032] len[49152] es[2] soff[1957175296]
May 18 18:03:59 dngo kernel: Ext[2] foff[221184] len[28672] es[2] soff[1957224448]

May 18 18:03:59 dngo kernel: XFS (sdb): pNFS inode 3846447 iomap dump
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[28672] len[12288] addr[1957031936] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[73728] len[65536] addr[1957076992] type[2] flags[0x0] state[0]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[139264] len[4096] addr[1957142528] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[143360] len[16384] addr[1957146624] type[2] flags[0x0] state[0]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[159744] len[4096] addr[1957163008] type[3] flags[0x0] state[1]
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[163840] len[8192] addr[1957167104] type[2] flags[0x0] state[0]  /* type_2: IOMAP_MAPPED */
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[172032] len[77824] addr[1957175296] type[3] flags[0x0] state[1] /* type_3: IOMAP_UNWRITTEN */
May 18 18:03:59 dngo kernel: xfs_pnfs_dump_inode_iomaps: off[258048] len[4096] addr[1957261312] type[3] flags[0x0] state[1]

As shown, the file map changes. Entry# 7 and 8 before the NFSD calls
merged into entry#7 after the calls. So there must be some activities
that cause the map to change. I don't know whether the activities were
triggered by NFS or something in XFS or the block device layer.

However, based on this data I think it's better to change the bmapi_flags
from XFS_BMAPI_ENTIRE to '0' to address the overlap issue.

-Dai