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
40 send_files_dir=$TEST_DIR/btrfs-test-$seq
43 rm -fr $send_files_dir
46 _scratch_mkfs >>$seqres.full 2>&1
52 touch $SCRATCH_MNT/a/file
56 touch $SCRATCH_MNT/e/file2
59 # Filesystem looks like:
63 # | |---- file (ino 260)
69 # | |--- file2 (ino 263)
73 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
75 # Now make inode 257 a child of inode 259 and rename inode 258 to the name that
76 # inode 257 had before. When the incremental send processes inode 257, it can't
77 # do the rename immediately because inode 259 must be renamed first, so inode's
78 # 257 rename is delayed and happens after the rename for inode 259 is done.
79 # Since send processes inodes by ascending order of their number, inode 258
80 # can't be renamed before inode 257 is renamed and therefore must be delayed
81 # as well. So the send stream must issue rename commands in the following order:
83 # 1 - rename inode 259 ('c' -> 'x')
84 # 2 - rename inode 257 ('a' -> 'x/y')
85 # 3 - rename inode 258 ('b' -> 'a')
87 # Before the fix mentioned above, the send stream attempted to rename inode 258
88 # before inode 257 was renamed, resulting in a client error mentioning
89 # 'directory not empty'.
91 # Same logic applies to 'd', 'e' and 'f', but the difference is that in the
92 # second snapshot 'e' is associated to an inode with a lower inode number than
93 # in the first snapshot.
95 mv $SCRATCH_MNT/c $SCRATCH_MNT/x
96 mv $SCRATCH_MNT/a $SCRATCH_MNT/x/y
97 mv $SCRATCH_MNT/b $SCRATCH_MNT/a
99 mv $SCRATCH_MNT/f $SCRATCH_MNT/f2
100 mv $SCRATCH_MNT/e $SCRATCH_MNT/f2/e2
101 mv $SCRATCH_MNT/d $SCRATCH_MNT/e
103 # Filesystem now looks like:
109 # | |---- y/ (ino 257)
110 # | |----- file (ino 260)
113 # |---- f2/ (ino 264)
114 # | |----- e2/ (ino 262)
115 # |---- file2 (ino 263)
117 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
119 run_check $FSSUM_PROG -A -f -w $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
120 run_check $FSSUM_PROG -A -f -w $send_files_dir/2.fssum \
121 -x $SCRATCH_MNT/mysnap2/mysnap1 $SCRATCH_MNT/mysnap2
123 _run_btrfs_util_prog send -f $send_files_dir/1.snap $SCRATCH_MNT/mysnap1
124 _run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 -f $send_files_dir/2.snap \
127 # Now recreate the filesystem by receiving both send streams and verify we get
128 # the same content that the original filesystem had.
130 _scratch_mkfs >>$seqres.full 2>&1
133 _run_btrfs_util_prog receive -f $send_files_dir/1.snap $SCRATCH_MNT
134 run_check $FSSUM_PROG -r $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
136 _run_btrfs_util_prog receive -f $send_files_dir/2.snap $SCRATCH_MNT
137 run_check $FSSUM_PROG -r $send_files_dir/2.fssum $SCRATCH_MNT/mysnap2
139 echo "Silence is golden"