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 _begin_fstest auto quick log
16 # Override the default cleanup function.
24 # Import common functions.
28 # real QA test starts here
31 _require_dm_target flakey
33 # The test requires a very specific layout of keys and items in the fs/subvolume
34 # btree to trigger a bug. So we want to make sure that on whatever platform we
35 # are, we have the same leaf/node size.
37 # Currently in btrfs the node/leaf size can not be smaller than the page
38 # size (but it can be greater than the page size). So use the largest
39 # supported node/leaf size (64K).
41 _scratch_mkfs "-n 65536" >>$seqres.full 2>&1
42 _require_metadata_journaling $SCRATCH_DEV
46 # "testdir" is inode 257.
47 mkdir $SCRATCH_MNT/testdir
48 chmod 755 $SCRATCH_MNT/testdir
50 # Create several empty files to have the directory "testdir" with its items
51 # spread over several leaves (7 in this case).
52 for ((i = 1; i <= 1200; i++)); do
53 echo -n > $SCRATCH_MNT/testdir/file$i
56 # Create our test directory "dira", inode number 1458, which gets all its items
59 # The BTRFS_DIR_ITEM_KEY item for inode 257 ("testdir") that points to the entry
60 # named "dira" is in leaf 2, while the BTRFS_DIR_INDEX_KEY item that points to
61 # that entry is in leaf 3.
63 # For this particular filesystem node size (64K), file count and file names, we
64 # endup with the directory entry items from inode 257 in leaves 2 and 3, as
65 # previously mentioned - what matters for triggering the bug exercised by this
66 # test case is that those items are not placed in leaf 1, they must be placed in
67 # a leaf different from the one containing the inode item for inode 257.
69 # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for the
70 # parent inode (257) are the following:
72 # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34
73 # location key (1458 INODE_ITEM 0) type DIR
74 # transid 6 data_len 0 name_len 4
79 # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34
80 # location key (1458 INODE_ITEM 0) type DIR
81 # transid 6 data_len 0 name_len 4
84 mkdir $SCRATCH_MNT/testdir/dira
86 # Make sure everything done so far is durably persisted.
89 # Now do a change to inode 257 ("testdir") that does not result in COWing leaves
90 # 2 and 3 - the leaves that contain the directory items pointing to inode 1458
93 # Changing permissions, the owner/group, updating or adding a xattr, etc, will
94 # not change (COW) leaves 2 and 3. So for the sake of simplicity change the
95 # permissions of inode 257, which results in updating its inode item and
96 # therefore change (COW) only leaf 1.
98 chmod 700 $SCRATCH_MNT/testdir
100 # Now fsync directory inode 257.
102 # Since only the first leaf was changed/COWed, we log the inode item of inode 257
103 # and only the entries found in the first leaf, all with a key of type
104 # BTRFS_DIR_ITEM_KEY, and no keys of type BTRFS_DIR_INDEX_KEY, because they sort
105 # after the former type and none exist in the first leaf.
107 # We also log 3 items that represent ranges for dir items and dir indexes for
108 # which the log is authoritative:
110 # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is
111 # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset in the
112 # range [0, 2285968570] (the offset here is the crc32c of the dentry's
113 # name). The value 2285968570 corresponds to the offset of the first key
114 # of leaf 2 (which is of type BTRFS_DIR_ITEM_KEY);
116 # 2) 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 [4293818216, (u64)-1] (the offset here is the crc32c of the dentry's
119 # name). The value 4293818216 corresponds to the offset of the highest key
120 # of type BTRFS_DIR_ITEM_KEY plus 1 (4293818215 + 1), which is located in
123 # 3) a key of type BTRFS_DIR_LOG_INDEX_KEY, with an offset of 1203, which
124 # indicates the log is authoritative for all keys of type BTRFS_DIR_INDEX_KEY
125 # that have an offset in the range [1203, (u64)-1]. The value 1203 corresponds
126 # to the offset of the last key of type BTRFS_DIR_INDEX_KEY plus 1 (1202 + 1),
127 # which is located in leaf 3;
129 # Also, because "testdir" is a directory and inode 1458 ("dira") is a child
130 # directory, we log inode 1458 too.
132 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/testdir
134 # Now move "dira", inode 1458, to be a child of the root directory (inode 256).
136 # Because this inode was previously logged, when "testdir" was fsynced, the
137 # log is updated so that the old inode reference, referring to inode 257 as
138 # the parent, is deleted and the new inode reference, referring to inode 256
139 # as the parent, is added to the log.
141 mv $SCRATCH_MNT/testdir/dira $SCRATCH_MNT/
143 # Now change some file and fsync it. This guarantees the log changes made by
144 # the previous move/rename operation are persisted. We do not need to do any
145 # special modification to the file, just any change to any file and sync the
147 $XFS_IO_PROG -c "pwrite -S 0xab 0 64K" \
149 $SCRATCH_MNT/testdir/file1 >>$seqres.full
151 # Simulate a power failure and then mount again the filesystem to replay the log
152 # tree. We want to verify that we are able to mount the filesystem, meaning log
153 # replay was successful, and that directory inode 1458 ("dira") only has inode
154 # 256 (the filesystem's root) as its parent (and no longer a child of inode 257).
156 # It used to happen that during log replay we would end up having inode 1458
157 # (directory "dira") with 2 hard links, being a child of inode 257 ("testdir")
158 # and inode 256 (the filesystem's root). This resulted in the tree checker
159 # detecting the issue and causing the mount operation to fail (with -EIO).
161 # This happened because in the log we have the new name/parent for inode 1458,
162 # which results in adding the new dentry with inode 256 as the parent, but the
163 # previous dentry, under inode 257 was never removed - this is because the
164 # ranges for dir items and dir indexes of inode 257 for which the log is
165 # authoritative do not include the old dir item and dir index for the dentry
166 # of inode 257 referring to inode 1458:
168 # - for dir items, the log is authoritative for the ranges [0, 2285968570] and
169 # [4293818216, (u64)-1]. The dir item at inode 257 pointing to inode 1458 has
170 # a key of (257 DIR_ITEM 3724298081), as previously mentioned, so the dir item
171 # is not deleted when the log replay procedure processes the authoritative
172 # ranges, as 3724298081 is outside both ranges;
174 # - for dir indexes, the log is authoritative for the range [1203, (u64)-1], and
175 # the dir index item of inode 257 pointing to inode 1458 has a key of
176 # (257 DIR_INDEX 1202), as previously mentioned, so the dir index item is not
177 # deleted when the log replay procedure processes the authoritative range.
179 _flakey_drop_and_remount
181 [ -d $SCRATCH_MNT/testdir/dira ] && echo "/testdir/dira still exists"
182 [ -d $SCRATCH_MNT/dira ] || echo "/dira does not exists"
184 # While at it also check that the data we wrote was not lost, just for the sake
186 echo "File $SCRATCH_MNT/testdir/file1 data:" | _filter_scratch
187 od -A d -t x1 $SCRATCH_MNT/testdir/file1