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

[Dave Chinner <dgc@kernel.org>]

On Mon, Nov 02, 2026 at 09:25:00PM -0800, Christoph Hellwig wrote:
> 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?

The problem is that we don't have a 'this inode has shared extents'
flag in the file_getattr() flag set, hence there is no easy way to
query if the inode may or may not have shared extents in it. That
would be trivial to add, and would avoid the need to FIEMAP every
single file in the fs to check for shared extents...

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

Efficient ad hoc physical extent status querying is what the
GETFSMAP ioctl is supposed to provide, right?

The owner of an physical extent is part of the input key filters, so
it extending the implementation to filter extents by owner field
would allow arbitrary per-file extent map lookups. e.g.
functionality like "report only shared extents for a given inode
number range" is well within the functional scope of this interface.

That allows dust to fstat a file to get the total block count and
inode number, call file_getattr() to see if the file has shared
extents, and then use fsmap to efficiently query the exact shared
extent list for that inode and so calculate the shared block count
for that inode number....

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org