Re: [PATCH] btrfs: test incremental send after cloning extents from the same file

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On 1/11/21 6:41 AM, fdmanana@xxxxxxxxxx wrote:
From: Filipe Manana <fdmanana@xxxxxxxx>

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 <fdmanana@xxxxxxxx>
---
  tests/btrfs/228     | 109 ++++++++++++++++++++++++++++++++++++++++++++
  tests/btrfs/228.out |  24 ++++++++++
  tests/btrfs/group   |   1 +
  3 files changed, 134 insertions(+)
  create mode 100755 tests/btrfs/228
  create mode 100644 tests/btrfs/228.out

diff --git a/tests/btrfs/228 b/tests/btrfs/228
new file mode 100755
index 00000000..0a3fb249
--- /dev/null
+++ b/tests/btrfs/228
@@ -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/228
+#
+# 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.
+#

Can you reference the commit title that fixes the problem?

+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+	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
+_require_test
+_require_scratch_reflink
+
+send_files_dir=$TEST_DIR/btrfs-test-$seq
+
+rm -f $seqres.full
+rm -fr $send_files_dir
+mkdir $send_files_dir
+
+_scratch_mkfs >>$seqres.full 2>&1
+_scratch_mount
+
+# 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 confure the algorithm used by the kernel
                                        ^^^^^^^
                                        confuse

otherwise you can add

Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx>

Thanks,

Josef



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux