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

[Christoph Hellwig <hch@infradead.org>]

On Fri, Nov 06, 2026 at 10:40:26PM +0200, Lauri Gates wrote:
> The other is that for a "may share" bit, clear is the unsafe answer,
> so a filesystem that cannot answer should not look like one that
> answers "not shared". As I understand it, stx_attributes_mask makes
> that distinction, while struct file_attr has no validity mask today
> (it is size-versioned, so one could be added), so through
> file_getattr() btrfs would currently read as never shared. A spare
> bit in stx_attributes adds no field to struct statx, which I hope
> meets the concern Christian raised about spending statx space on the
> case-folding RFC [2]. If fileattr is preferred, the bit could instead
> mean "no shared extents", so that clear is the safe default, as it is
> for FS_XFLAG_CASEFOLD.

statx sounds good to me, but I'd really like to hear from Christian.

> 
> > Besides xfs, btrfs and ocfs2 also support reflinks, and nfs (and maybe
> > cifs?) can export the semanics remotely.  So we really need a way
> > to indicate if the file system could support reflinks to start with,
> > and then one that the file could, so we probably need two bits
> 
> For du, I think the mask could stand in for the "could support
> reflinks" bit if it means "this filesystem can answer for this file":
> 
>   mask clear            not reported, fall back to FIEMAP
>   mask set, bit clear   no shared extents
>   mask set, bit set     may have shared extents
> 
> A filesystem that cannot share extents at all would set the mask and
> leave the bit clear.

Sounds good.

>  - nfs, cifs: I could not find a per-file attribute in NFSv4.2 or
>    MS-FSCC that could carry it (space_freed comes closest, and nfsd
>    does not implement it), so no mask bit there.

There's definitively nothing in NFS, speaking as the person who added
the clone support.  If your new Linux syscall API becomes widely useful,
we could add the equivalent to NFS in a new draft.

> A filesystem-level "could reflink" bit might be a separate need:
> nfsd encodes clone_blksize for every export and ksmbd advertises
> FILE_SUPPORTS_BLOCK_REFCOUNTING unconditionally, I assume because
> neither can ask the exported filesystem. Did you have nfsd and ksmbd
> in mind for that bit?

I just mean we need some way to discover it.  I think the three states
in statx should cover everything.

> On reliability, my tentative answer is that the bit does not need to
> be exact for this use. A clear bit must never be wrong,

Yes.

> Stale bits do limit what it saves, though. The flag stays set when
> the other copy is deleted or the file is overwritten; only truncation
> to zero and FALLOC_FL_UNSHARE_RANGE (see the caveat below) clear it.

Yes.

> Would there be a reasonable point for XFS to clear the flag once
> sharing ends? I don't know the code well enough to tell what that
> would cost.

It is hard to know that nothing is shared, because nothing in the
inode tracks the shared space, except for XFS_DIFLAG2_REFLINK only
the reflink btree shared if anyting is reflinked.   To efficiently
clear the bit in an exact way we'd need to track the number of
blocks or extents that are shared in the inode, which would be
an on-disk format change.  But if you run xfs_scrub with online
repair enable, the online repair can fix the value up as background
operation, which should be useful once that feature has matured a
bit and users enable it by default.

> 
> The caveat, which may be unintended or may be my misreading:
> FALLOC_FL_UNSHARE_RANGE over a whole shared file does not clear the
> flag on the first call. bpftrace on 7.2 shows
> xfs_reflink_clear_inode_flag() entered and
> xfs_reflink_inode_has_shared_extents() not, so it looks like
> xfs_can_free_cowblocks() returned false, perhaps on I_DIRTY_PAGES
> left by the unshare. A second call after sync clears the flag.

Interesting.  Maybe we need a sync before calling
xfs_reflink_inode_has_shared_extents?

> If the statx direction sounds reasonable, I would be glad to put
> together an RFC with the uapi bit, xfs and ocfs2 support, a man-pages
> patch and an xfstest. This would be my first kernel patch, so
> corrections on any of the above are very welcome.

Happy to help reviewing this if you take on a word.  Just as a warning
I'm a bit overloaded currently, so some replies might take longer than
I'd want.