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

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

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

Understood, and that is why I am looking at the alternatives below.

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

Thanks, that answers it. If shared buffer locks are ever tried, I can
run the reproducer against the patches.

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

A whole-device total would be useful on its own, but du tools mostly
report per directory. dust handles the boundary by counting each
shared extent once within the scanned tree, so a block shared with a
file outside the scan is charged to the scan in full. That is a policy
choice, and it needs to know which files own which shared blocks.

GETFSMAP already returns that: with rmapbt, each shared range comes
back once per owning inode. On a test image with 100,000 reflinked
pairs (7.2.12, arm64 VM, xfsprogs 6.6.0 defaults, which enable rmapbt),
a whole-device fsmap walk took about 120 ms, against 387 ms for a
single-threaded FIEMAP walk of the same 200,000 files. But it returns
owners only with CAP_SYS_ADMIN, as ioctl_fsmap(2) documents, so it
covers a du tool run as root and not one run as an ordinary user.

Would the refcount-sum ioctl you describe be callable without
CAP_SYS_ADMIN? A device-wide total reveals much less than per-file
owners.

On the dust side, a per-AG mutex in userspace removes the worst case,
threads in one AG running slower than a single thread, but recovers
little parallelism when threads are already spread over AGs.

Thanks,
Lauri