btrfs: test incremental send after cloning extents from the same file
authorFilipe Manana <>
Mon, 11 Jan 2021 11:41:54 +0000 (11:41 +0000)
committerEryu Guan <>
Sun, 17 Jan 2021 14:14:36 +0000 (22:14 +0800)
Test that an incremental send operation correctly issues clone operations
for a file that had different parts of one of its extents cloned into
itself, at different offsets, and a large part of that extent was
overwritten, so all the reflinks only point to subranges of the extent.

This currently fails on btrfs but is fixed by a patch for the kernel that
has the following subject:

 "btrfs: send, fix invalid clone operations when cloning from the same file and root"

Signed-off-by: Filipe Manana <>
Reviewed-by: Josef Bacik <>
Signed-off-by: Eryu Guan <>
tests/btrfs/229 [new file with mode: 0755]
tests/btrfs/229.out [new file with mode: 0644]

diff --git a/tests/btrfs/229 b/tests/btrfs/229
new file mode 100755 (executable)
index 0000000..19026f2
--- /dev/null
@@ -0,0 +1,109 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2021 SUSE Linux Products GmbH. All Rights Reserved.
+# FS QA Test No. btrfs/229
+# Test that an incremental send operation correctly issues clone operations for
+# a file that had different parts of one of its extents cloned into itself, at
+# different offsets, and a large part of that extent was overwritten, so all the
+# reflinks only point to subranges of the extent.
+seq=`basename $0`
+echo "QA output created by $seq"
+status=1       # failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+       cd /
+       rm -fr $send_files_dir
+       rm -f $tmp.*
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+. ./common/reflink
+# real QA test starts here
+_supported_fs btrfs
+rm -f $seqres.full
+rm -fr $send_files_dir
+mkdir $send_files_dir
+_scratch_mkfs >>$seqres.full 2>&1
+# Create our test file with a single and large extent (1M) and with different
+# content for different file ranges that will be reflinked later.
+$XFS_IO_PROG -f \
+            -c "pwrite -S 0xab 0 128K" \
+            -c "pwrite -S 0xcd 128K 128K" \
+            -c "pwrite -S 0xef 256K 256K" \
+            -c "pwrite -S 0x1a 512K 512K" \
+            $SCRATCH_MNT/foobar | _filter_xfs_io
+# Now create the base snapshot, which is going to be the parent snapshot for
+# a later incremental send.
+$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
+       $SCRATCH_MNT/mysnap1 > /dev/null
+$BTRFS_UTIL_PROG send -f $send_files_dir/1.snap \
+       $SCRATCH_MNT/mysnap1 2>&1 1>/dev/null | _filter_scratch
+# Now do a series of changes to our file such that we end up with different
+# parts of the extent reflinked into different file offsets and we overwrite
+# a large part of the extent too, so no file extent items refer to that part
+# that was overwritten. This used to confuse the algorithm used by the kernel
+# to figure out which file ranges to clone, making it attempt to clone from
+# a source range starting at the current eof of the file, resulting in the
+# receiver to fail since it is an invalid clone operation.
+$XFS_IO_PROG -c "reflink $SCRATCH_MNT/foobar 64K 1M 960K" \
+            -c "reflink $SCRATCH_MNT/foobar 0K 512K 256K" \
+            -c "reflink $SCRATCH_MNT/foobar 512K 128K 256K" \
+            -c "pwrite -S 0x73 384K 640K" \
+            $SCRATCH_MNT/foobar | _filter_xfs_io
+$BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT \
+                $SCRATCH_MNT/mysnap2 > /dev/null
+$BTRFS_UTIL_PROG send -p $SCRATCH_MNT/mysnap1 -f $send_files_dir/2.snap \
+                $SCRATCH_MNT/mysnap2 2>&1 1>/dev/null | _filter_scratch
+echo "File digest in the original filesystem:"
+_md5_checksum $SCRATCH_MNT/mysnap2/foobar
+# Now recreate the filesystem by receiving both send streams and verify we get
+# the same content that the original filesystem had.
+_scratch_mkfs >>$seqres.full 2>&1
+$BTRFS_UTIL_PROG receive -f $send_files_dir/1.snap $SCRATCH_MNT > /dev/null
+# The receive operation below used to fail with the following error:
+#    ERROR: failed to clone extents to foobar: Invalid argument
+# This is because the send stream included a clone operation to clone from the
+# current file eof into eof (we can't clone from eof and neither the source
+# range can overlap with the destination range), resulting in the receiver to
+# fail with -EINVAL when attempting the clone operation.
+$BTRFS_UTIL_PROG receive -f $send_files_dir/2.snap $SCRATCH_MNT > /dev/null
+# Must match what we had in the original filesystem.
+echo "File digest in the new filesystem:"
+_md5_checksum $SCRATCH_MNT/mysnap2/foobar
diff --git a/tests/btrfs/229.out b/tests/btrfs/229.out
new file mode 100644 (file)
index 0000000..0a54533
--- /dev/null
@@ -0,0 +1,24 @@
+QA output created by 229
+wrote 131072/131072 bytes at offset 0
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 131072/131072 bytes at offset 131072
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 262144/262144 bytes at offset 262144
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 524288/524288 bytes at offset 524288
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+At subvol SCRATCH_MNT/mysnap1
+linked 983040/983040 bytes at offset 1048576
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+linked 262144/262144 bytes at offset 524288
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+linked 262144/262144 bytes at offset 131072
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 655360/655360 bytes at offset 393216
+XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+At subvol SCRATCH_MNT/mysnap2
+File digest in the original filesystem:
+At subvol mysnap1
+File digest in the new filesystem:
index dc8b41f90c06d644f32300eb393b91339fc53861..79347b8fc2e0a17b1eac467588016d245bb1543d 100644 (file)
 226 auto quick rw snapshot clone prealloc punch
 227 auto quick send
 228 auto quick volume
+229 auto quick send clone