2 # FS QA Test No. btrfs/092
4 # Test btrfs incremental send after renaming and moving directories around in a
5 # way that ends up making a directory have different dentries with the same name
6 # but pointing to different inodes in the parent and send snapshots, and also
7 # inverting the ancestor-descendent relationship between one of those inodes and
10 # Cases like this made an incremental send enter an infinite lopp when building
11 # path strings, leading to -ENOMEM errors when the path string reached a length
13 # This issue was fixed by the following linux kernel btrfs patch:
15 # Btrfs: incremental send, check if orphanized dir inode needs delayed rename
17 #-----------------------------------------------------------------------
18 # Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
19 # Author: Filipe Manana <fdmanana@suse.com>
21 # This program is free software; you can redistribute it and/or
22 # modify it under the terms of the GNU General Public License as
23 # published by the Free Software Foundation.
25 # This program is distributed in the hope that it would be useful,
26 # but WITHOUT ANY WARRANTY; without even the implied warranty of
27 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
28 # GNU General Public License for more details.
30 # You should have received a copy of the GNU General Public License
31 # along with this program; if not, write the Free Software Foundation,
32 # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
33 #-----------------------------------------------------------------------
37 seqres=$RESULT_DIR/$seq
38 echo "QA output created by $seq"
41 status=1 # failure is the default!
42 trap "_cleanup; exit \$status" 0 1 2 3 15
46 rm -fr $send_files_dir
50 # get standard environment, filters and checks
54 # real QA test starts here
60 send_files_dir=$TEST_DIR/btrfs-test-$seq
63 rm -fr $send_files_dir
66 _scratch_mkfs >>$seqres.full 2>&1
69 mkdir -p $SCRATCH_MNT/data/n1/n2
70 mkdir $SCRATCH_MNT/data/n4
71 mkdir -p $SCRATCH_MNT/data/t6/t7
72 mkdir $SCRATCH_MNT/data/t5
73 mkdir $SCRATCH_MNT/data/t7
74 mkdir $SCRATCH_MNT/data/n4/t2
75 mkdir $SCRATCH_MNT/data/t4
76 mkdir $SCRATCH_MNT/data/t3
77 mv $SCRATCH_MNT/data/t7 $SCRATCH_MNT/data/n4/t2
78 mv $SCRATCH_MNT/data/t4 $SCRATCH_MNT/data/n4/t2/t7
79 mv $SCRATCH_MNT/data/t5 $SCRATCH_MNT/data/n4/t2/t7/t4
80 mv $SCRATCH_MNT/data/t6 $SCRATCH_MNT/data/n4/t2/t7/t4/t5
81 mv $SCRATCH_MNT/data/n1/n2 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6
82 mv $SCRATCH_MNT/data/n1 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6
83 mv $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/t7 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n2
84 mv $SCRATCH_MNT/data/t3 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n2/t7
86 # Filesystem looks like:
101 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
103 # The sequence of directory rename operations below made the btrfs incremental
104 # send implementation enter an infinite loop when building path strings. The
105 # reason for this was the following:
107 # * While processing inode 262 it ended up orphanizing inode 264 (rename it to
108 # "/o264-6-0"). This is because the parent inode 265 has a dentry with name
109 # t7 in the parent snapshot that refers to inode 264, which is ahead of the
110 # current send progress (inode 262) and our inode 262 has the name t7 in
111 # the directory inode 265 in the send snapshot - so in order to rename inode
112 # 262 to its new name/location, it orphanizes (renames) 264 before 264 is
115 # * When it processes inode 264 it was not checking if it needed to delay its
116 # rename operation. This was incorrect because in the parent snapshot inode
117 # 267 is a descendent of inode 264 and inode 267 is an ancestor of inode 264
118 # in the send snapshot, which means the rename of inode 264 must happen after
119 # inode 267 is renamed in order to avoid the infinite loops when building
120 # path strings that involved inodes 264 and 267;
122 # * As a consequence as soon as the send progress moved to inode 265, the
123 # following loop when building a path string for inode 264 happened:
125 # start inode 264, send progress of 265 for example
126 # parent of 264 -> 267
127 # parent of 267 -> 262
128 # parent of 262 -> 259
129 # parent of 259 -> 261
130 # parent of 261 -> 263
131 # parent of 263 -> 266
132 # parent of 266 -> 264
133 # |--> back to first iteration while current path string length
134 # is <= PATH_MAX, and fail with -ENOMEM otherwise
136 mv $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n1 $SCRATCH_MNT/data/n4
137 mv $SCRATCH_MNT/data/n4/t2 $SCRATCH_MNT/data/n4/n1
138 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4/t5/t6/n2 $SCRATCH_MNT/data/n4/n1/t2
139 mv $SCRATCH_MNT/data/n4/n1/t2/n2/t7/t3 $SCRATCH_MNT/data/n4/n1/t2
140 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4/t5/t6 $SCRATCH_MNT/data/n4/n1/t2
141 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4 $SCRATCH_MNT/data/n4/n1/t2/t6
142 mv $SCRATCH_MNT/data/n4/n1/t2/t7 $SCRATCH_MNT/data/n4/n1/t2/t3
143 mv $SCRATCH_MNT/data/n4/n1/t2/n2/t7 $SCRATCH_MNT/data/n4/n1/t2
145 # Filesystem now looks like:
148 # |-- data/ (ino 257)
157 # | |-- t4/ (ino 266)
158 # | |-- t5/ (ino 263)
162 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
164 run_check $FSSUM_PROG -A -f -w $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
165 run_check $FSSUM_PROG -A -f -w $send_files_dir/2.fssum \
166 -x $SCRATCH_MNT/mysnap2/mysnap1 $SCRATCH_MNT/mysnap2
168 _run_btrfs_util_prog send -f $send_files_dir/1.snap $SCRATCH_MNT/mysnap1
169 _run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 -f $send_files_dir/2.snap \
172 # Now recreate the filesystem by receiving both send streams and verify we get
173 # the same content that the original filesystem had.
175 _scratch_mkfs >>$seqres.full 2>&1
178 _run_btrfs_util_prog receive -f $send_files_dir/1.snap $SCRATCH_MNT
179 run_check $FSSUM_PROG -r $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
180 _run_btrfs_util_prog receive -f $send_files_dir/2.snap $SCRATCH_MNT
181 run_check $FSSUM_PROG -r $send_files_dir/2.fssum $SCRATCH_MNT/mysnap2
183 echo "Silence is golden"