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

[Dave Chinner <dgc@kernel.org>]

On Wed, Nov 04, 2026 at 02:41:16PM +0200, Lauri Gates wrote:
> 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.

fsmap() takes an arbitrary open fd on the filesystem being queried.
We could allow owner-based queries if the owner in the filter key
matches the inode backing the fd that is passed into the query. If
the task already has a file open for that inode, then it's already
been given permission to access/read metadata for that file (same as
FIEMAP).

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org