From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E38F41F7C8 for ; Fri, 14 Aug 2026 08:23:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786695815; cv=none; b=FwwxPnzJRR3Ct+jXO+4X6xxrLMxAiSBPXBAboBgaly7CCLMV7KimON1gdiRZMEsF3ydKG70yjIue53NOMoEZOSD7aWI7F95dfStlIdt7hmFmPQi4zqWUndj7qytc88X+59rzaPGEZfkL4/RCMHm9tlHPDC6ddepC3JD668Zbidc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786695815; c=relaxed/simple; bh=AYi6XN6L+ooLAzjDbjw5n6K1PLJzuIAPnkRJZYc6P/o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LbRJ10Hu9QpxUg/SgKTpVTXoMeZ+9X95cnrWkmS2jiV2+7MLl3A/lAoZ8vFQXX1RcYSUVrj4qP3C/QAZJxPg1iBB/kHqj4kTm+eCf898kHzL0aaB7+btIMKZkwK7gyVe9bOmgaLa9+OdlEpR13cEj148hXj43FLWZ8wNRXGwZUc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=BFhTdoVE; arc=none smtp.client-ip=209.85.216.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BFhTdoVE" Received: by mail-pj1-f53.google.com with SMTP id 98e67ed59e1d1-38dcbade417so768247a91.1 for ; Fri, 14 Aug 2026 01:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786695810; x=1787300610; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mdwrDZQ/B1XCL4tbfkMD/QBVbfJkQDSMykw+X/F3Z3Y=; b=BFhTdoVE/SP+i1kwHMJEgyYIPuMkAikZnC11BDcBPHkC551AHeILeFZ1an7uuW9qU5 qz+UB+EJQIAZwlx6iVwcjbPzIeJl+HEK/SH1QhNNkiJCJPfwiMgmKv8D42rnYvHUtYQG rNElNdY39IGavpkE9Z/p3i7Ay3dUOkZtsEuRmO2mlKUHUjTGsoQOMvQ5+q9Ee2aInQx1 6kkSiYirnDFZW3z2CVptAbxM+5xwOzgovQea4543gS6kBGe7a//Y2Byoc4XCyBdzAjrr yUSwtxKTwQc7nPRKUgwtNare55yuWoFVqQ0nGFl++g4u/5JGzfJx/dyeJQKetTjJNEdk icOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786695810; x=1787300610; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=mdwrDZQ/B1XCL4tbfkMD/QBVbfJkQDSMykw+X/F3Z3Y=; b=G3vOq8KPcDgksx4EDELe6q0fI+R8XBZVmIF9Qiq8bciIsea3spUXwwGETKlBUtd/a6 iq4SWcD8FpbC3ApOl4e/PgwU1JxUd+vlp+RXU3GQxOeC2D2cpU+CsqDg26kJ8ExXx1sJ rZ9r2/PRaH/pL9rFrNGtNS1NFh9542M5Ton1Agm6RRFkWeyR3XaDnJfgYNKKfnz4MeJD RoF2qe2M6rbfcvBU3TeSIjw/NM68sVL8QCHfkkz6n7NM9R6KABFaG8HMpHUmTNXmPpY2 YO3YQtLOTYODhPmhtp0R75ZiOnCTYzPRtZVymtjZT9lattTPbFt8eHFYm3hmqmAr51hi CZXw== X-Forwarded-Encrypted: i=1; AHgh+RrOZWBzP7zJ+fsapQtvK0nK3NKNqg2kV2ZHjkqf2wdj3CgcxO18UApzPIXoAVEd81RKDjUPueU1feNTGF8=@vger.kernel.org X-Gm-Message-State: AOJu0YwqYpep0ngdZ1sVbYChavgI6R3ME3fHnAh+wjjwQpms/V0GhnmU gdVMvqlLac95Zyp7hF/eMuxLAROeoB2pVcqUPJ0r1CUUtqv3xeVNrkvq X-Gm-Gg: AR+sD12JRryrULsK2aWI/kG72t1B6ky8lRzkViZvzlvbffvRboPv+NFVjFQXSsvbqtI +OTwybs5SVEW1s13t+dLwrsWuEN/aj6+DJM7QfnKIhNd9Eq6NhIQhsEStsxOA3aeUtgvFkwuMTr y+ak4QtcVosaRUiCLHtLv9l+K+WFsR3xLUlsVs+CZNp62GDNGkrujXuUxgZi0v2luiHL/lU0F+E wYr926AFNH6JiIq3JFNBIxOa3ETGbW6Beq0GQR23jqKhLShvJy7RsPRFCiU+MebAtFdWx5gAlZ9 lGnGGVwSp6k+oyRzqTGpfNC8kgRnOXshNc30+K3k5U2EGs92Vlhg2/TEjpaEDFUQ7VCpSAQ4kcj Lbqv4VDgtt+Z3drIwFVfLbXLihSuKTvK99qrxhhvnbcjQjgU4uAv7FFwxJl+TjumlMqcKYHdXc7 7kjuRXUm/Ze2Ec6avQurBY/34VanM3B5bT9bvstA3zjqsvv0xfgbuJkXq26FQRTypxJS9cCX34U ZopIcEldHGnsUmy00YJff7V34AlhM3C9tnQ4f/yi8peVAZBey0NYNdjgx5caOmX/ahjXkqqARuv /i6svYrXp9it8QkXeVAAovXPtSIszPv0h1ND5gKyHniEqdiXoE9TWPIummMRGM0= X-Received: by 2002:a17:90b:264d:b0:392:b509:b1a5 with SMTP id 98e67ed59e1d1-3933b93e1aamr4664814a91.14.1786695810219; Fri, 14 Aug 2026 01:23:30 -0700 (PDT) Received: from spider.bream-herring.ts.net ([103.252.203.158]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-394ebb888cbsm1588075a91.9.2026.08.14.01.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 14 Aug 2026 01:23:29 -0700 (PDT) From: Matthias Goergens 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 v2 0/1] vfs: add FILE_DEDUPE_RANGE_REPORT_PROGRESS flag to FIDEDUPERANGE Date: Fri, 14 Aug 2026 16:23:25 +0800 Message-ID: <20260814082326.3756669-1-matthias.goergens@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260805071414.3414870-1-matthias.goergens@gmail.com> References: <20260805071414.3414870-1-matthias.goergens@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Changes since v1 (<20260805071414.3414870-1-matthias.goergens@gmail.com>): Darrick is right that bytes_deduped = len predates the VFS hoisting - the manpage describes the behaviour the patch would introduce, not the historical default, and deployed consumers (duperemove advances file offsets by bytes_deduped) depend on the old semantics. v2 therefore keeps the default unchanged and gates the truthful behaviour behind a new flag: - FILE_DEDUPE_RANGE_REPORT_PROGRESS (the former reserved2 field is now flags): bytes_deduped reports the bytes actually deduplicated, and a non-zero request shortened to zero fails per destination with -EINVAL instead of reporting success with no progress. - Unknown flag bits are rejected with -EINVAL. The fstests series will follow in the same shape: the generic/517 golden output stays as it is (unflagged behaviour is unchanged), and the new test exercises the flag, including one unflagged case pinning the legacy reporting. Darrick also notes the manpage is wrong - with the flag in place, the right fix is to document the flag in ioctl_fideduperange(2) rather than change the default; a man-pages patch can follow once the flag name and semantics are settled. Amir: you reviewed the v1 logic favourably - could you have a look at the flag shape instead? In particular: the name (FILE_DEDUPE_RANGE_REPORT_PROGRESS), the semantics (actual bytes plus -EINVAL on zero progress), and whether the manpage fix should ride along with the kernel patch or follow separately. If this shape works for you, the Reviewed-by on the flagged behaviour would be very welcome.