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

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

Hi Dave,

Thank you for your feedback.

On 5/15/26 2:39 PM, Dave Chinner wrote:
> 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.

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.

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.

-Dai

>
> 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.