Re: [PATCH 0/2] vfs: report truthful FIDEDUPERANGE progress safely

On Wed, Aug 12, 2026 at 9:46 AM Christian Brauner <[email protected]> wrote:
>
> On 2026-08-05 15:14 +0800, Matthias Goergens wrote:
> > FIDEDUPERANGE currently reports the requested length even when the
> > filesystem shortens a destination range and deduplicates fewer bytes. A
> > previous one-line correction was reverted after generic/517 exposed the old
> > expectation and reviewers raised the risk that existing consumers could loop
> > on a successful zero-progress result.
> >
> > Patch 1 makes a non-zero request shortened to zero fail per destination with
> > -EINVAL, while preserving explicit zero-length success. Patch 2 then reports
> > the filesystem's actual positive progress. This ordering keeps every
> > intermediate kernel safe for callers that advance by bytes_deduped.
> >
> > The paired fstests update corrects generic/517 and adds raw ioctl coverage for
> > zero-length and mixed multi-destination results. Both tests pass on Btrfs and
> > XFS. Installed duperemove exits successfully on the measured corpus. Installed
> > rmlint does not hang or silently over-report; it exits 1 after the final
> > unaligned tail receives -EINVAL, which is recorded explicitly for review.
> >
> > A current-source consumer audit supports that ABI choice: duperemove completes
> > the request on a non-zero status; rmlint, bees and jdupes surface -EINVAL as
> > failure without retrying; dduper and xfs_io stop but can still report command
> > success. None retries, hangs or risks data corruption. Thus -EINVAL is the
> > only truthful result that also avoids exposing successful zero progress to
> > deployed duperemove binaries.
> >
> > Matthias Goergens (2):
> >   vfs: fail dedupe requests that cannot make progress
> >   vfs: report the amount of bytes actually deduplicated
>
> Needs input from Amir.
>

The logic seems sound to me.
Main well tested and accounted for,
the suggested fixed already aligned with the man page documentation
even:
EINVAL The  filesystem does not support deduplicating the ranges of
the given files.
could be interpreted to apply to this unaligned dedupe case

Feel free to add
Reviewed-by: Amir Goldstein <[email protected]>

to both patches,

Thanks,
Amir.