From: Matthias Goergens <matthias.goergens@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: 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: [PATCH v3] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE
Date: Mon, 17 Aug 2026 19:56:09 +0800 [thread overview]
Message-ID: <20260817115609.3586664-2-matthias.goergens@gmail.com> (raw)
In-Reply-To: <20260817115609.3586664-1-matthias.goergens@gmail.com>
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
FILE_DEDUPE_RANGE_REPORT_PROGRESS set, bytes_deduped in each
destination's info is an advance hint for the next call on that
destination:
- if status is an error, bytes_deduped is 0;
- if status is FILE_DEDUPE_RANGE_DIFFERS, bytes_deduped is a safe
advance step: one filesystem block, capped to the requested length
so a sub-block request ending at EOF cannot be advanced past its
end, and falling back to the requested length when the top-level
inode reports a degenerate block size (stacked filesystems);
- if status is FILE_DEDUPE_RANGE_SAME, bytes_deduped is the number of
bytes actually deduplicated;
- in both success cases a zero value means no further work is
possible.
Unknown flag bits are rejected. The flags field shares an anonymous
union with the old reserved2 name, so existing source keeps compiling
and the binary layout is unchanged; old kernels require the field to
be zero, so new callers setting the flag on old kernels get -EINVAL
rather than silently the old semantics.
Suggested-by: Darrick J. Wong <djwong@kernel.org>
Link: https://lore.kernel.org/linux-fsdevel/20260805071414.3414870-1-matthias.goergens@gmail.com/
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
fs/remap_range.c | 25 +++++++++++++++++++++----
include/uapi/linux/fs.h | 5 ++++-
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/fs/remap_range.c b/fs/remap_range.c
index 26afbbbfb10c2..ac88a81c12739 100644
--- a/fs/remap_range.c
+++ b/fs/remap_range.c
@@ -503,7 +503,7 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
if (!(file->f_mode & FMODE_READ))
return -EINVAL;
- if (same->reserved1 || same->reserved2)
+ if (same->reserved1 || (same->flags & ~FILE_DEDUPE_RANGE_REPORT_PROGRESS))
return -EINVAL;
off = same->src_offset;
@@ -551,12 +551,29 @@ int vfs_dedupe_file_range(struct file *file, struct file_dedupe_range *same)
deduped = vfs_dedupe_file_range_one(file, off, fd_file(dst_fd),
info->dest_offset, len,
REMAP_FILE_CAN_SHORTEN);
- if (deduped == -EBADE)
+ if (deduped == -EBADE) {
info->status = FILE_DEDUPE_RANGE_DIFFERS;
- else if (deduped < 0)
+ if (same->flags & FILE_DEDUPE_RANGE_REPORT_PROGRESS) {
+ u64 step = i_blocksize(src);
+
+ /*
+ * Stacked filesystems (e.g. overlayfs) can
+ * report a degenerate block size here; a
+ * one-byte step would only misalign the
+ * next call, so advance past the whole
+ * request instead.
+ */
+ if (step <= 1)
+ step = len;
+ info->bytes_deduped = min_t(u64, step, len);
+ }
+ } else if (deduped < 0) {
info->status = deduped;
- else
+ } else if (same->flags & FILE_DEDUPE_RANGE_REPORT_PROGRESS) {
+ info->bytes_deduped = deduped;
+ } else {
info->bytes_deduped = len;
+ }
next_loop:
if (fatal_signal_pending(current))
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index bd87262f2e349..471f698beaa93 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -178,13 +178,16 @@ struct file_dedupe_range_info {
__u32 reserved; /* must be zero */
};
+/* flags for struct file_dedupe_range */
+#define FILE_DEDUPE_RANGE_REPORT_PROGRESS (1U << 0)
+
/* from struct btrfs_ioctl_file_extent_same_args */
struct file_dedupe_range {
__u64 src_offset; /* in - start of extent in source */
__u64 src_length; /* in - length of extent */
__u16 dest_count; /* in - total elements in info array */
__u16 reserved1; /* must be zero */
- __u32 reserved2; /* must be zero */
+ __u32 flags; /* in - FILE_DEDUPE_RANGE_* flags */
struct file_dedupe_range_info info[];
};
--
2.55.0
next prev parent reply other threads:[~2026-08-17 11:56 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 ` Matthias Goergens [this message]
2026-08-18 8:50 ` [PATCH v3] " Christoph Hellwig
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=20260817115609.3586664-2-matthias.goergens@gmail.com \
--to=matthias.goergens@gmail.com \
--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=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®