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

[Lauri Gates <lauri.gates@gmail.com>]

On Thu, Nov 05, 2026 at 08:04:15AM +1100, Dave Chinner wrote:
> 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...

That would help most trees: for a file without the flag, a du tool
could skip open + FIEMAP + close and make one file_getattr() call by
path. On 100,000 never-reflinked files, warm cache, with open + FIEMAP
+ close run in one process per worker so the shared fd table stays out
of the comparison (file_getattr() opens nothing):

                                open+FIEMAP+close  file_getattr()
  Ryzen 9 3900X, 6.17, 24 workers        27.5 ms         11.3 ms
  GCP n2-standard-8, 7.0, 8 workers      49.3 ms         21.4 ms

Mirroring XFS_DIFLAG2_REFLINK, the flag would mean "may have shared
extents", which is all a du tool needs to decide whether to look
closer. If it helps, I can write the patch.

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

I tried the nearest thing that works today: per file, a GETFSMAP query
limited to that file's physical range, taken from an untimed FIEMAP
beforehand, so the best case for an owner-filtered query. As root on
the same GCP VM, same 100,000 files, one process per worker:

                       1 worker   8 workers
  open+FIEMAP+close      200 ms      49 ms
  per-file GETFSMAP      560 ms     564 ms

Each query reads the AGF in __xfs_getfsmap_datadev() and holds it for
that AG's walk, so concurrent queries queue on the AGF buffer lock,
also for never-reflinked files, where FIEMAP returns before the
refcount lookup. In a traced run with 4 threads, bpftrace put every
D-state switch in xfs_buf_lock() under xfs_alloc_read_agf() and
xfs_getfsmap(). And since the rmapbt key orders by physical block
before owner, an owner filter would need the inode's extents mapped
first to avoid walking the whole rmapbt.

So for a scan that touches every file, I expect it to stay slower
than FIEMAP unless the AGF can be held shared. Am I missing a way to
use it here? The permission model from your other reply, the owner
matching the inode behind the fd, makes sense to me; the cost per
query is what I am unsure about.

Thanks,
Lauri