2 # SPDX-License-Identifier: GPL-2.0
3 # Copyright (C) 2021 SUSE Linux Products GmbH. All Rights Reserved.
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.
14 seqres=$RESULT_DIR/$seq
15 echo "QA output created by $seq"
17 status=1 # failure is the default!
18 trap "_cleanup; exit \$status" 0 1 2 3 15
27 # get standard environment, filters and checks
32 # real QA test starts here
35 _require_dm_target flakey
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.
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).
47 _scratch_mkfs "-n 65536" >>$seqres.full 2>&1
48 _require_metadata_journaling $SCRATCH_DEV
52 # "testdir" is inode 257.
53 mkdir $SCRATCH_MNT/testdir
54 chmod 755 $SCRATCH_MNT/testdir
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
62 # Create our test directory "dira", inode number 1458, which gets all its items
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.
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.
75 # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for the
76 # parent inode (257) are the following:
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
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
90 mkdir $SCRATCH_MNT/testdir/dira
92 # Make sure everything done so far is durably persisted.
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
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.
104 chmod 700 $SCRATCH_MNT/testdir
106 # Now fsync directory inode 257.
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.
113 # We also log 3 items that represent ranges for dir items and dir indexes for
114 # which the log is authoritative:
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);
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
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;
135 # Also, because "testdir" is a directory and inode 1458 ("dira") is a child
136 # directory, we log inode 1458 too.
138 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir
140 # Now move "dira", inode 1458, to be a child of the root directory (inode 256).
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.
147 mv $SCRATCH_MNT/testdir/dira $SCRATCH_MNT/
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
153 $XFS_IO_PROG -c "pwrite -S 0xab 0 64K" \
155 $SCRATCH_MNT/testdir/file1 >>$seqres.full
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).
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).
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:
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;
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.
185 _flakey_drop_and_remount
187 [ -d $SCRATCH_MNT/testdir/dira ] && echo "/testdir/dira still exists"
188 [ -d $SCRATCH_MNT/dira ] || echo "/dira does not exists"
190 # While at it also check that the data we wrote was not lost, just for the sake
192 echo "File $SCRATCH_MNT/testdir/file1 data:" | _filter_scratch
193 od -A d -t x1 $SCRATCH_MNT/testdir/file1