btrfs: test log replay after directory fsync and moving a child directory
[xfstests-dev.git] / tests / btrfs / 239
1 #! /bin/bash
2 # SPDX-License-Identifier: GPL-2.0
3 # Copyright (C) 2021 SUSE Linux Products GmbH. All Rights Reserved.
4 #
5 # FSQA Test No. 239
6 #
7 # Test a particular scenario where we fsync a directory, then move one of its
8 # children directories into another directory and then finally sync the log
9 # trees by fsyncing any other inode. We want to check that after a power failure
10 # we are able to mount the filesystem and that the moved directory exists only
11 # as a child of the directory we moved it into.
12 #
13 seq=`basename $0`
14 seqres=$RESULT_DIR/$seq
15 echo "QA output created by $seq"
16 tmp=/tmp/$$
17 status=1        # failure is the default!
18 trap "_cleanup; exit \$status" 0 1 2 3 15
19
20 _cleanup()
21 {
22         _cleanup_flakey
23         cd /
24         rm -f $tmp.*
25 }
26
27 # get standard environment, filters and checks
28 . ./common/rc
29 . ./common/filter
30 . ./common/dmflakey
31
32 # real QA test starts here
33 _supported_fs btrfs
34 _require_scratch
35 _require_dm_target flakey
36
37 rm -f $seqres.full
38
39 # The test requires a very specific layout of keys and items in the fs/subvolume
40 # btree to trigger a bug. So we want to make sure that on whatever platform we
41 # are, we have the same leaf/node size.
42 #
43 # Currently in btrfs the node/leaf size can not be smaller than the page
44 # size (but it can be greater than the page size). So use the largest
45 # supported node/leaf size (64K).
46 #
47 _scratch_mkfs "-n 65536" >>$seqres.full 2>&1
48 _require_metadata_journaling $SCRATCH_DEV
49 _init_flakey
50 _mount_flakey
51
52 # "testdir" is inode 257.
53 mkdir $SCRATCH_MNT/testdir
54 chmod 755 $SCRATCH_MNT/testdir
55
56 # Create several empty files to have the directory "testdir" with its items
57 # spread over several leaves (7 in this case).
58 for ((i = 1; i <= 1200; i++)); do
59         echo -n > $SCRATCH_MNT/testdir/file$i
60 done
61
62 # Create our test directory "dira", inode number 1458, which gets all its items
63 # in leaf 7.
64 #
65 # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to the entry
66 # named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY item that points to
67 # that entry is in leaf 3.
68 #
69 # For this particular filesystem node size (64K), file count and file names, we
70 # endup with the directory entry items from inode 257 in leaves 2 and 3, as
71 # previously mentioned - what matters for triggering the bug exercised by this
72 # test case is that those items are not placed in leaf 1, they must be placed in
73 # a leaf different from the one containing the inode item for inode 257.
74 #
75 # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for the
76 # parent inode (257) are the following:
77 #
78 #           item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34
79 #                location key (1458 INODE_ITEM 0) type DIR
80 #                transid 6 data_len 0 name_len 4
81 #                name: dira
82 #
83 # and:
84 #
85 #           item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34
86 #                location key (1458 INODE_ITEM 0) type DIR
87 #                transid 6 data_len 0 name_len 4
88 #                name: dira
89 #
90 mkdir $SCRATCH_MNT/testdir/dira
91
92 # Make sure everything done so far is durably persisted.
93 sync
94
95 # Now do a change to inode 257 ("testdir") that does not result in COWing leaves
96 # 2 and 3 - the leaves that contain the directory items pointing to inode 1458
97 # (directory "dira").
98 #
99 # Changing permissions, the owner/group, updating or adding a xattr, etc, will
100 # not change (COW) leaves 2 and 3. So for the sake of simplicity change the
101 # permissions of inode 257, which results in updating its inode item and
102 # therefore change (COW) only leaf 1.
103 #
104 chmod 700 $SCRATCH_MNT/testdir
105
106 # Now fsync directory inode 257.
107 #
108 # Since only the first leaf was changed/COWed, we log the inode item of inode 257
109 # and only the entries found in the first leaf, all with a key of type
110 # BTRFS_DIR_ITEM_KEY, and no keys of type BTRFS_DIR_INDEX_KEY, because they sort
111 # after the former type and none exist in the first leaf.
112 #
113 # We also log 3 items that represent ranges for dir items and dir indexes for
114 # which the log is authoritative:
115 #
116 # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is
117 #    authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset in the
118 #    range [0, 2285968570] (the offset here is the crc32c of the dentry's
119 #    name). The value 2285968570 corresponds to the offset of the first key
120 #    of leaf 2 (which is of type BTRFS_DIR_ITEM_KEY);
121 #
122 # 2) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is
123 #    authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset in the
124 #    range [4293818216, (u64)-1] (the offset here is the crc32c of the dentry's
125 #    name). The value 4293818216 corresponds to the offset of the highest key
126 #    of type BTRFS_DIR_ITEM_KEY plus 1 (4293818215 + 1), which is located in
127 #    leaf 2;
128 #
129 # 3) a key of type BTRFS_DIR_LOG_INDEX_KEY, with an offset of 1203, which
130 #    indicates the log is authoritative for all keys of type BTRFS_DIR_INDEX_KEY
131 #    that have an offset in the range [1203, (u64)-1]. The value 1203 corresponds
132 #    to the offset of the last key of type BTRFS_DIR_INDEX_KEY plus 1 (1202 + 1),
133 #    which is located in leaf 3;
134 #
135 # Also, because "testdir" is a directory and inode 1458 ("dira") is a child
136 # directory, we log inode 1458 too.
137 #
138 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir
139
140 # Now move "dira", inode 1458, to be a child of the root directory (inode 256).
141 #
142 # Because this inode was previously logged, when "testdir" was fsynced, the
143 # log is updated so that the old inode reference, referring to inode 257 as
144 # the parent, is deleted and the new inode reference, referring to inode 256
145 # as the parent, is added to the log.
146 #
147 mv $SCRATCH_MNT/testdir/dira $SCRATCH_MNT/
148
149 # Now change some file and fsync it. This guarantees the log changes made by
150 # the previous move/rename operation are persisted. We do not need to do any
151 # special modification to the file, just any change to any file and sync the
152 # log.
153 $XFS_IO_PROG -c "pwrite -S 0xab 0 64K" \
154              -c "fsync" \
155              $SCRATCH_MNT/testdir/file1 >>$seqres.full
156
157 # Simulate a power failure and then mount again the filesystem to replay the log
158 # tree. We want to verify that we are able to mount the filesystem, meaning log
159 # replay was successful, and that directory inode 1458 ("dira") only has inode
160 # 256 (the filesystem's root) as its parent (and no longer a child of inode 257).
161 #
162 # It used to happen that during log replay we would end up having inode 1458
163 # (directory "dira") with 2 hard links, being a child of inode 257 ("testdir")
164 # and inode 256 (the filesystem's root). This resulted in the tree checker
165 # detecting the issue and causing the mount operation to fail (with -EIO).
166 #
167 # This happened because in the log we have the new name/parent for inode 1458,
168 # which results in adding the new dentry with inode 256 as the parent, but the
169 # previous dentry, under inode 257 was never removed - this is because the
170 # ranges for dir items and dir indexes of inode 257 for which the log is
171 # authoritative do not include the old dir item and dir index for the dentry
172 # of inode 257 referring to inode 1458:
173 #
174 # - for dir items, the log is authoritative for the ranges [0, 2285968570] and
175 #   [4293818216, (u64)-1]. The dir item at inode 257 pointing to inode 1458 has
176 #   a key of (257 DIR_ITEM 3724298081), as previously mentioned, so the dir item
177 #   is not deleted when the log replay procedure processes the authoritative
178 #   ranges, as 3724298081 is outside both ranges;
179 #
180 # - for dir indexes, the log is authoritative for the range [1203, (u64)-1], and
181 #   the dir index item of inode 257 pointing to inode 1458 has a key of
182 #   (257 DIR_INDEX 1202), as previously mentioned, so the dir index item is not
183 #   deleted when the log replay procedure processes the authoritative range.
184 #
185 _flakey_drop_and_remount
186
187 [ -d $SCRATCH_MNT/testdir/dira ] && echo "/testdir/dira still exists"
188 [ -d $SCRATCH_MNT/dira ] || echo "/dira does not exists"
189
190 # While at it also check that the data we wrote was not lost, just for the sake
191 # of completeness.
192 echo "File $SCRATCH_MNT/testdir/file1 data:" | _filter_scratch
193 od -A d -t x1 $SCRATCH_MNT/testdir/file1
194
195 _unmount_flakey
196
197 status=0
198 exit