Re: (2) [PATCH] nfsd: do not return overlapping extents in a block layout

[Chuck Lever]

On Wed, Oct 7, 2026, at 9:47 PM, Daejun Park wrote:
> On Wed, Oct 07, 2026 at 09:51:01AM -0700, Darrick J. Wong wrote:
>> Nitpicking here, but the extent could extend beyond than the requested
>> @offset/@length range too, right?  Shouldn't the comment say that, since
>> the header comment allows for both cases, right?
>
> Yes, it can end past offset + length. Chuck had already applied the
> patch to nfsd-testing (214e388464bf) when your reply came, so the
> comment there still says "may be shorter than the requested length".
>
> The ->map_blocks series that Christoph asked for removes that comment:
>
> https://lore.kernel.org/r/20261008-xfs-nfsd-map-blocks-v1-0-560026cdccb6@xxxxxxxxxxx
>
> nfsd4_block_map_extent() becomes nfsd4_block_iomap_to_extent(), which
> only converts a mapping, and the ->map_blocks comment says that the
> last mapping may end before or after @offset + @len.
>
> If Chuck would rather fix it in nfsd-testing in the meantime, the
> comment would read:
>
> /*
>  * Get an extent from the file system that contains offset. It may start
>  * below offset and may end before or after offset + length.
>  */

I don't quite understand the logistics / ordering, as it appears to
invite a conflict depending on which tree the ->map_blocks series
goes through.


-- 
Chuck Lever (Come to NFS bake-a-thon! https://nfsv4bat.org)