[PATCH v4 0/2] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE

[Matthias Goergens <matthias.goergens@gmail.com>]

Christoph, fair enough, and sorry for the delay. v4 follows with the
changelog rewritten to start from the callers: dedupe tools advance
their file offsets by bytes_deduped, the kernel can shorten a request to
a block boundary but reports the requested length, and rmlint on an
ordinary invocation therefore reports a pair as fully deduplicated with
the last 1696 bytes of it not shared.

Checking the v4 text against the code turned up two changes of
substance.

The DIFFERS advance hint from v3 is gone. The comparison covers the
whole shortened range and stops at the first mismatch anywhere in it,
so on DIFFERS the kernel has no mismatch offset to report; a one-block
hint would tell a caller to skip a block that may match. v4
reports 0 on DIFFERS and leaves subdividing to the caller, which is
what rmlint already does. Darrick, on your sketch specifically: that is
why I dropped it; if you still want a hint there, I would rather it be
the compared length than one block.

Patch 1 is new: dax_dedupe_file_range_compare() returns the positive
iomap_iter() count instead of the comparison error, and XFS passes that
up as the remap result. Today the ioctl masks it by reporting the
requested length; with the flag it would surface as a successful
one-byte dedupe, so it needs fixing first.

Also corrected from v3: its text described the flags field as a union
with the old reserved2 name, but the diff was a plain rename. v4 has the
union; both spellings compile and the struct size is unchanged. And the
changelog now attributes the shortening to generic_remap_checks(), which
runs before the comparison; v3 named generic_remap_check_len(), which
runs after it.

Two things I looked at and left alone, so that they are on record:
ocfs2 returns 0 after copying inline data for a whole-file request, so
under the flag that case reports SAME with 0 (FICLONERANGE already gets
-EINVAL there today); and kernels before 4.5 ignored the reserved
field in the btrfs ioctl, so only 4.5 and later reject the flag.

The fstests test for the flag (generic/806 v2 on the fstests list) was
written for the v3 semantics and needs a v3 of its own; that and the
ioctl_fideduperange(2) man-page update follow once this settles.

Changes since v3
(https://lore.kernel.org/linux-fsdevel/20260817115609.3586664-2-matthias.goergens@gmail.com/):
- Changelog rewritten to start from the callers and the measured rmlint
  case (Christoph).
- DIFFERS no longer carries an advance hint; bytes_deduped is 0 there.
- New patch 1 fixing the DAX comparator's return value.
- The flags field is an anonymous union with reserved2, as the v3 text
  already claimed; v3's diff was a plain rename.
- Shortening attributed to generic_remap_checks(); v3 named
  generic_remap_check_len(), which runs after the comparison.

Matthias Goergens (2):
  dax: return the comparison error from dax_dedupe_file_range_compare()
  vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE

 fs/dax.c                | 2 +-
 fs/remap_range.c        | 4 +++-
 include/uapi/linux/fs.h | 8 +++++++-
 3 files changed, 11 insertions(+), 3 deletions(-)

-- 
2.55.0