2 # SPDX-License-Identifier: GPL-2.0
3 # Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
5 # FS QA Test No. btrfs/083
7 # Test for incremental send where the difference between the parent and child
8 # snapshots is that a directory A was renamed and a directory B was renamed to
9 # the name directory A had before (in the parent snapshot), but directory A's
10 # rename must happen before some other directory C is renamed.
12 # This issue was fixed by the following linux kernel btrfs patch:
14 # Btrfs: incremental send, don't rename a directory too soon
17 seqres=$RESULT_DIR/$seq
18 echo "QA output created by $seq"
21 status=1 # failure is the default!
22 trap "_cleanup; exit \$status" 0 1 2 3 15
26 rm -fr $send_files_dir
30 # get standard environment, filters and checks
34 # real QA test starts here
39 send_files_dir=$TEST_DIR/btrfs-test-$seq
42 rm -fr $send_files_dir
45 _scratch_mkfs >>$seqres.full 2>&1
51 touch $SCRATCH_MNT/a/file
55 touch $SCRATCH_MNT/e/file2
58 # Filesystem looks like:
62 # | |---- file (ino 260)
68 # | |--- file2 (ino 263)
72 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
74 # Now make inode 257 a child of inode 259 and rename inode 258 to the name that
75 # inode 257 had before. When the incremental send processes inode 257, it can't
76 # do the rename immediately because inode 259 must be renamed first, so inode's
77 # 257 rename is delayed and happens after the rename for inode 259 is done.
78 # Since send processes inodes by ascending order of their number, inode 258
79 # can't be renamed before inode 257 is renamed and therefore must be delayed
80 # as well. So the send stream must issue rename commands in the following order:
82 # 1 - rename inode 259 ('c' -> 'x')
83 # 2 - rename inode 257 ('a' -> 'x/y')
84 # 3 - rename inode 258 ('b' -> 'a')
86 # Before the fix mentioned above, the send stream attempted to rename inode 258
87 # before inode 257 was renamed, resulting in a client error mentioning
88 # 'directory not empty'.
90 # Same logic applies to 'd', 'e' and 'f', but the difference is that in the
91 # second snapshot 'e' is associated to an inode with a lower inode number than
92 # in the first snapshot.
94 mv $SCRATCH_MNT/c $SCRATCH_MNT/x
95 mv $SCRATCH_MNT/a $SCRATCH_MNT/x/y
96 mv $SCRATCH_MNT/b $SCRATCH_MNT/a
98 mv $SCRATCH_MNT/f $SCRATCH_MNT/f2
99 mv $SCRATCH_MNT/e $SCRATCH_MNT/f2/e2
100 mv $SCRATCH_MNT/d $SCRATCH_MNT/e
102 # Filesystem now looks like:
108 # | |---- y/ (ino 257)
109 # | |----- file (ino 260)
112 # |---- f2/ (ino 264)
113 # | |----- e2/ (ino 262)
114 # |---- file2 (ino 263)
116 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
118 run_check $FSSUM_PROG -A -f -w $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
119 run_check $FSSUM_PROG -A -f -w $send_files_dir/2.fssum \
120 -x $SCRATCH_MNT/mysnap2/mysnap1 $SCRATCH_MNT/mysnap2
122 _run_btrfs_util_prog send -f $send_files_dir/1.snap $SCRATCH_MNT/mysnap1
123 _run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 -f $send_files_dir/2.snap \
126 # Now recreate the filesystem by receiving both send streams and verify we get
127 # the same content that the original filesystem had.
129 _scratch_mkfs >>$seqres.full 2>&1
132 _run_btrfs_util_prog receive -f $send_files_dir/1.snap $SCRATCH_MNT
133 run_check $FSSUM_PROG -r $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
135 _run_btrfs_util_prog receive -f $send_files_dir/2.snap $SCRATCH_MNT
136 run_check $FSSUM_PROG -r $send_files_dir/2.fssum $SCRATCH_MNT/mysnap2
138 echo "Silence is golden"