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

[Dave Chinner <dgc@kernel.org>]

On Thu, May 14, 2026 at 10:19:14AM -0700, Dai Ngo wrote:
> On 5/13/26 5:25 PM, Darrick J. Wong wrote:
> > On Wed, May 13, 2026 at 10:28:31AM -0700, Dai Ngo wrote:
> > > IMHO, I think we still should fix xfs_fs_map_blocks() to avoid any overhead
> > > and complication in ext_tree_insert having to handle overlapping extents.
> > I don't know enough about the nfs blocklayout code to say for sure, but
> > it seems like you want to upsert the mapping returned by
> > xfs_fs_map_blocks into the "ext_tree" right?
> 
> This is currently done on the NFS client side by ext_tree_insert(). The
> question I have is should we enhance the server side by passing '0' to
> xfs_fs_map_blocks() so the client does not have to do the work of
> handling the overlap extents.

I think you've all missed the optimal solution to the problem. 

The problem is not the use of XFS_BMAPI_ENTIRE on the first mapping
call, it's the use of it on the -second- after the first call didn't
return a range that mapped the -entire- request range.

Hence the second and subsequent calls need range trimming so that
they don't overlap with the first range that was returned.

IOWs, we keep the use XFS_BMAPI_ENTIRE for the first mapping call
so we retain the optimisation that minimises the number of pNFS
client mapping calls needed, but if it needs to make a second call
we drop the ENTIRE flag and append extents trimmed to the range
being asked for (which doesn't include the first extent already
returned).

That was we get large extents reported most of the time, and in the
corner cases where we have a race like this one or an extent
boundary lies in the middle of the requested range, we will get
correct, non-overlapping behaviour.

Best of both worlds, yes?

-Dave.
-- 
Dave Chinner
dgc@kernel.org