Re: FIDEDUPERANGE with src_length == 0
From: Darrick J. Wong <hidden>
Date: 2016-07-13 05:27:00
Also in:
linux-fsdevel
On Mon, Jul 11, 2016 at 05:35:37PM -0700, Omar Sandoval wrote:
quoted hunk ↗ jump to hunk
Hey, Darrick, generic/182 is failing on Btrfs for me with the following output:--- tests/generic/182.out 2016-07-07 19:51:54.000000000 -0700 +++ /tmp/fixxfstests/xfstests/results//generic/182.out.bad 2016-07-11 17:28:28.230039216 -0700@@ -1,12 +1,10 @@ QA output created by 182 Create the original files -dedupe: Extents did not match. f4820540fc0ac02750739896fe028d56 TEST_DIR/test-182/file1 69ad53078a16243d98e21d9f8704a071 TEST_DIR/test-182/file2 69ad53078a16243d98e21d9f8704a071 TEST_DIR/test-182/file2.chk Compare against check files Make the original file almost dedup-able -dedupe: Extents did not match. f4820540fc0ac02750739896fe028d56 TEST_DIR/test-182/file1 158d4e3578b94b89cbb44493a2110fb9 TEST_DIR/test-182/file2 158d4e3578b94b89cbb44493a2110fb9 TEST_DIR/test-182/file2.chkIt looks like that test is checking that a dedupe with length == 0 is treated as a dedupe to EOF, but Btrfs doesn't do that [1]. As far as I can tell, it never did, but maybe I'm just confused. What was the behavior when you introduced that test? That seems like a reasonable thing to do, but I wanted to clear this up before changing/fixing Btrfs.
It's a shortcut that we're introducing in the upcoming XFS implementation, since it shares the same back end as clone/clonerange, which both have this behavior. --D
Thanks. 1: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ioctl.c?h=v4.7-rc7#n3122 -- Omar