4 # Test that if we fsync a file that got one extent partially cloned into a
5 # lower file offset, after a power failure our file has the same content it
6 # had before the power failure and after the extent cloning operation.
8 #-----------------------------------------------------------------------
10 # Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
11 # Author: Filipe Manana <fdmanana@suse.com>
13 # This program is free software; you can redistribute it and/or
14 # modify it under the terms of the GNU General Public License as
15 # published by the Free Software Foundation.
17 # This program is distributed in the hope that it would be useful,
18 # but WITHOUT ANY WARRANTY; without even the implied warranty of
19 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
20 # GNU General Public License for more details.
22 # You should have received a copy of the GNU General Public License
23 # along with this program; if not, write the Free Software Foundation,
24 # Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
25 #-----------------------------------------------------------------------
29 seqres=$RESULT_DIR/$seq
30 echo "QA output created by $seq"
32 status=1 # failure is the default!
33 trap "_cleanup; exit \$status" 0 1 2 3 15
41 # get standard environment, filters and checks
46 # real QA test starts here
51 _require_dm_target flakey
53 _require_metadata_journaling $SCRATCH_DEV
57 _scratch_mkfs >>$seqres.full 2>&1
61 BLOCK_SIZE=$(get_block_size $SCRATCH_MNT)
63 # Create our test file with a single 25 block extent starting at file offset
64 # mapped by 200th block We fsync the file here to make the fsync log tree get a
65 # single csum item that covers the whole 25 block extent, which causes the
66 # second fsync, done after the cloning operation below, to not leave in the log
67 # tree two csum items covering two block sub-ranges ([0, 5[ and [5, 25[)) of our
69 $XFS_IO_PROG -f -c "pwrite -S 0xaa $((200 * $BLOCK_SIZE)) $((25 * $BLOCK_SIZE))" \
71 $SCRATCH_MNT/foo | _filter_xfs_io_blocks_modified
74 # Now clone part of our extent into file offset mapped by 100th block. This adds
75 # a file extent item to our inode's metadata that points to the 25 block extent
76 # we created before, using a data offset of 5 blocks and a data length of 5
77 # blocks, so that it refers to the block sub-range [5, 10[ of our original
79 $CLONER_PROG -s $(((200 * $BLOCK_SIZE) + (5 * $BLOCK_SIZE))) \
80 -d $((100 * $BLOCK_SIZE)) -l $((5 * $BLOCK_SIZE)) \
81 $SCRATCH_MNT/foo $SCRATCH_MNT/foo
83 # Now fsync our file to make sure the extent cloning is durably persisted. This
84 # fsync will not add a second csum item to the log tree containing the checksums
85 # for the blocks in the block sub-range [5, 10[ of our extent, because there was
86 # already a csum item in the log tree covering the whole extent, added by the
87 # first fsync we did before.
88 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
90 echo "File contents before power failure:"
91 od -t x1 $SCRATCH_MNT/foo | _filter_od
93 # The fsync log replay first processes the file extent item corresponding to the
94 # file offset mapped by 100th block (the one which refers to the [5, 10[ block
95 # sub-range of our 25 block extent) and then processes the file extent item for
96 # file offset mapped by 200th block. It used to happen that when processing the
97 # later, it erroneously left in the csum tree 2 csum items that overlapped each
98 # other, 1 for the block sub-range [5, 10[ and 1 for the whole range of our
99 # extent. This introduced a problem where subsequent lookups for the checksums
100 # of blocks within the block range [10, 25[ of our extent would not find
101 # anything because lookups in the csum tree ended up looking only at the smaller
102 # csum item, the one covering the block subrange [5, 10[. This made read
103 # requests assume an expected checksum with a value of 0 for those blocks, which
104 # caused checksum verification failure when the read operations finished.
105 # However those checksum failure did not result in read requests returning an
106 # error to user space (like -EIO for e.g.) because the expected checksum value
107 # had the special value 0, and in that case btrfs set all bytes of the
108 # corresponding pages with the value 0x01 and produce the following warning in
111 # "BTRFS warning (device dm-0): csum failed ino 257 off 917504 csum 1322675045\
114 _flakey_drop_and_remount
116 echo "File contents after log replay:"
117 # Must match the file contents we had after cloning the extent and before
118 # the power failure happened.
119 od -t x1 $SCRATCH_MNT/foo | _filter_od