tests/btrfs/098

   1 #! /bin/bash
   2 # SPDX-License-Identifier: GPL-2.0
   3 # Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
   4 #
   5 # FSQA Test No. 098
   6 #
   7 # Test that if we fsync a file that got one extent partially cloned into a
   8 # lower file offset, after a power failure our file has the same content it
   9 # had before the power failure and after the extent cloning operation.
  10 #
  11 seq=`basename $0`
  12 seqres=$RESULT_DIR/$seq
  13 echo "QA output created by $seq"
  14 tmp=/tmp/$$
  15 status=1        # failure is the default!
  16 trap "_cleanup; exit \$status" 0 1 2 3 15
  17
  18 _cleanup()
  19 {
  20         _cleanup_flakey
  21         rm -f $tmp.*
  22 }
  23
  24 # get standard environment, filters and checks
  25 . ./common/rc
  26 . ./common/filter
  27 . ./common/dmflakey
  28
  29 # real QA test starts here
  30 _supported_fs btrfs
  31 _supported_os Linux
  32 _require_scratch
  33 _require_dm_target flakey
  34 _require_cloner
  35
  36 rm -f $seqres.full
  37
  38 _scratch_mkfs >>$seqres.full 2>&1
  39 _require_metadata_journaling $SCRATCH_DEV
  40 _init_flakey
  41 _mount_flakey
  42
  43 BLOCK_SIZE=$(_get_block_size $SCRATCH_MNT)
  44
  45 # Create our test file with a single 25 block extent starting at file offset
  46 # mapped by 200th block We fsync the file here to make the fsync log tree get a
  47 # single csum item that covers the whole 25 block extent, which causes the
  48 # second fsync, done after the cloning operation below, to not leave in the log
  49 # tree two csum items covering two block sub-ranges ([0, 5[ and [5, 25[)) of our
  50 # extent.
  51 $XFS_IO_PROG -f -c "pwrite -S 0xaa $((200 * $BLOCK_SIZE)) $((25 * $BLOCK_SIZE))" \
  52                 -c "fsync"                     \
  53                 $SCRATCH_MNT/foo | _filter_xfs_io_blocks_modified
  54
  55
  56 # Now clone part of our extent into file offset mapped by 100th block. This adds
  57 # a file extent item to our inode's metadata that points to the 25 block extent
  58 # we created before, using a data offset of 5 blocks and a data length of 5
  59 # blocks, so that it refers to the block sub-range [5, 10[ of our original
  60 # extent.
  61 $CLONER_PROG -s $(((200 * $BLOCK_SIZE) + (5 * $BLOCK_SIZE))) \
  62              -d $((100 * $BLOCK_SIZE)) -l $((5 * $BLOCK_SIZE)) \
  63              $SCRATCH_MNT/foo $SCRATCH_MNT/foo
  64
  65 # Now fsync our file to make sure the extent cloning is durably persisted. This
  66 # fsync will not add a second csum item to the log tree containing the checksums
  67 # for the blocks in the block sub-range [5, 10[ of our extent, because there was
  68 # already a csum item in the log tree covering the whole extent, added by the
  69 # first fsync we did before.
  70 $XFS_IO_PROG -c "fsync" $SCRATCH_MNT/foo
  71
  72 echo "File contents before power failure:"
  73 od -t x1 $SCRATCH_MNT/foo | _filter_od
  74
  75 # The fsync log replay first processes the file extent item corresponding to the
  76 # file offset mapped by 100th block (the one which refers to the [5, 10[ block
  77 # sub-range of our 25 block extent) and then processes the file extent item for
  78 # file offset mapped by 200th block. It used to happen that when processing the
  79 # later, it erroneously left in the csum tree 2 csum items that overlapped each
  80 # other, 1 for the block sub-range [5, 10[ and 1 for the whole range of our
  81 # extent. This introduced a problem where subsequent lookups for the checksums
  82 # of blocks within the block range [10, 25[ of our extent would not find
  83 # anything because lookups in the csum tree ended up looking only at the smaller
  84 # csum item, the one covering the block subrange [5, 10[. This made read
  85 # requests assume an expected checksum with a value of 0 for those blocks, which
  86 # caused checksum verification failure when the read operations finished.
  87 # However those checksum failure did not result in read requests returning an
  88 # error to user space (like -EIO for e.g.) because the expected checksum value
  89 # had the special value 0, and in that case btrfs set all bytes of the
  90 # corresponding pages with the value 0x01 and produce the following warning in
  91 # dmesg/syslog:
  92 #
  93 #  "BTRFS warning (device dm-0): csum failed ino 257 off 917504 csum 1322675045\
  94 #    expected csum 0"
  95 #
  96 _flakey_drop_and_remount
  97
  98 echo "File contents after log replay:"
  99 # Must match the file contents we had after cloning the extent and before
 100 # the power failure happened.
 101 od -t x1 $SCRATCH_MNT/foo | _filter_od
 102
 103 _unmount_flakey
 104
 105 status=0
 106 exit