From: Christoph Hellwig <hch@infradead.org>
To: Matthias Goergens <matthias.goergens@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, jack@suse.cz, linux-kernel@vger.kernel.org,
ansgar.loesser@kom.tu-darmstadt.de, djwong@kernel.org,
david@fromorbit.com, amir73il@gmail.com
Subject: Re: [PATCH v3] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE
Date: Tue, 18 Aug 2026 01:50:04 -0700 [thread overview]
Message-ID: <aoQcvGw4UmkMKmUz@infradead.org> (raw)
In-Reply-To: <20260817115609.3586664-2-matthias.goergens@gmail.com>
On Mon, Aug 17, 2026 at 07:56:09PM +0800, Matthias Goergens wrote:
> On success FIDEDUPERANGE reports the requested length in bytes_deduped
> even when the filesystem shortens a destination range and deduplicates
> fewer bytes. This predates the VFS hoisting of the ioctl (the btrfs
> ioctl behaved the same way), and changing the default would change an
> ABI that deployed consumers such as duperemove depend on: they advance
> their offsets by bytes_deduped and expect the historical semantics.
>
> Add a flag to opt into the truthful behaviour. With
What is "truthful"? It just is different. And you completely fail
to explain why it is useful here, instead spewing a weird AI-like
monologue just duplicating the patch content.
Start with why you care, i.e. what application or type of application
cares how much actually was deduplicated, and how you define the
user visible behavior of that having happened.
prev parent reply other threads:[~2026-08-18 8:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 7:14 [PATCH 0/2] vfs: report truthful FIDEDUPERANGE progress safely Matthias Goergens
2026-08-05 7:14 ` [PATCH 1/2] vfs: fail dedupe requests that cannot make progress Matthias Goergens
2026-08-05 7:14 ` [PATCH 2/2] vfs: report the amount of bytes actually deduplicated Matthias Goergens
2026-08-12 7:46 ` [PATCH 0/2] vfs: report truthful FIDEDUPERANGE progress safely Christian Brauner
2026-08-13 15:33 ` Amir Goldstein
2026-08-13 20:09 ` Darrick J. Wong
2026-08-14 8:23 ` [PATCH v2 0/1] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE Matthias Goergens
2026-08-14 8:23 ` [PATCH v2] " Matthias Goergens
2026-08-14 16:16 ` Darrick J. Wong
2026-08-17 11:56 ` [PATCH v3 0/1] " Matthias Goergens
2026-08-17 11:56 ` [PATCH v3] " Matthias Goergens
2026-08-18 8:50 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aoQcvGw4UmkMKmUz@infradead.org \
--to=hch@infradead.org \
--cc=amir73il@gmail.com \
--cc=ansgar.loesser@kom.tu-darmstadt.de \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthias.goergens@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®