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.chk It 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. Thanks. 1: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/btrfs/ioctl.c?h=v4.7-rc7#n3122 -- Omar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
