Re: Concurrent FIEMAP on reflinked files serialises on the AGF buffer lock

[Christoph Hellwig <hch@infradead.org>]

Hi Lauri,

On Mon, Nov 02, 2026 at 09:32:45PM +0200, Lauri Gates wrote:
> Hi,
> 
> FIEMAP on files with XFS_DIFLAG2_REFLINK set does not scale across
> threads. For every written extent, xfs_read_iomap_begin() calls
> xfs_reflink_trim_around_shared() (IOMAP_REPORT), which goes to
> xfs_reflink_find_shared() and reads the AGF of the extent's AG with
> xfs_alloc_read_agf(pag, NULL, 0, &agbp). Concurrent callers queue on
> that buffer's b_sema. A parallel du-style scan of a reflinked tree
> stops scaling at roughly the AG count, and threads working in the same
> AG run slower than one thread alone.

FIEMAP is purely a debug interface for file system developers.  So
running it in parallel for lots of files is highly unexpected and
suggests a misuse of the interface.

> My question, in more detail at the end: does reporting the shared flag
> for FIEMAP need the AGF buffer locked?

It needs to protect against agf_refcount_level changing, so yes.
In theory it would be fine with a shared lock on the AGF buffer if
we had a shared/exclusive lock on the buffers (which is something
I've wondered about a few times before), or some other high-level
synchronization against adding more reflinks.

> I ran into this adding a shared-block mode to dust, a du clone, which
> FIEMAPs every file and counts FIEMAP_EXTENT_SHARED extents once.
> Inodes without the reflink flag return early and are unaffected.

Ok, so this is the use case.  The more efficient way to do this
would be to subtract the multiple mapped extents based on the
refcount btree, i.e.

	for each AG (and RTG with rtreflink):
		for each entry in the (rt)refcountbt:
			subtract rc_blockcount * (rc_refcount - 1);

We'd need a new ioctl for that, but it should be pretty easy.
The major downside is that this only works for whole-device du,
but then also any other version would have a really hard time figuring
out what to do with reflinks the span the reported/not reported
boundary.

> I am not suggesting dropping the flag. Commit 5f9268ca53ac ("xfs:
> don't bother looking at the refcount tree for reads") kept
> IOMAP_REPORT on the refcount lookup deliberately, and Dave described
> the shared flag as a field diagnostic for reflinked files:
> https://lore.kernel.org/all/20210124214346.GC4626@dread.disaster.area/

IOMAP_REPORT/FIEMAP reporting the shared flag is probably exactly what
your tool relies on...