tests/btrfs/092

   1 #! /bin/bash
   2 # SPDX-License-Identifier: GPL-2.0
   3 # Copyright (C) 2015 SUSE Linux Products GmbH. All Rights Reserved.
   4 #
   5 # FS QA Test No. btrfs/092
   6 #
   7 # Test btrfs incremental send after renaming and moving directories around in a
   8 # way that ends up making a directory have different dentries with the same name
   9 # but pointing to different inodes in the parent and send snapshots, and also
  10 # inverting the ancestor-descendent relationship between one of those inodes and
  11 # some other inode.
  12 #
  13 # Cases like this made an incremental send enter an infinite lopp when building
  14 # path strings, leading to -ENOMEM errors when the path string reached a length
  15 # of PATH_MAX.
  16 # This issue was fixed by the following linux kernel btrfs patch:
  17 #
  18 #   Btrfs: incremental send, check if orphanized dir inode needs delayed rename
  19 #
  20 . ./common/preamble
  21 _begin_fstest auto quick send
  22
  23 # Override the default cleanup function.
  24 _cleanup()
  25 {
  26         rm -fr $send_files_dir
  27         rm -f $tmp.*
  28 }
  29
  30 # Import common functions.
  31 . ./common/filter
  32
  33 # real QA test starts here
  34 _supported_fs btrfs
  35 _require_scratch
  36 _require_fssum
  37
  38 send_files_dir=$TEST_DIR/btrfs-test-$seq
  39
  40 rm -fr $send_files_dir
  41 mkdir $send_files_dir
  42
  43 _scratch_mkfs >>$seqres.full 2>&1
  44 _scratch_mount
  45
  46 mkdir -p $SCRATCH_MNT/data/n1/n2
  47 mkdir $SCRATCH_MNT/data/n4
  48 mkdir -p $SCRATCH_MNT/data/t6/t7
  49 mkdir $SCRATCH_MNT/data/t5
  50 mkdir $SCRATCH_MNT/data/t7
  51 mkdir $SCRATCH_MNT/data/n4/t2
  52 mkdir $SCRATCH_MNT/data/t4
  53 mkdir $SCRATCH_MNT/data/t3
  54 mv $SCRATCH_MNT/data/t7 $SCRATCH_MNT/data/n4/t2
  55 mv $SCRATCH_MNT/data/t4 $SCRATCH_MNT/data/n4/t2/t7
  56 mv $SCRATCH_MNT/data/t5 $SCRATCH_MNT/data/n4/t2/t7/t4
  57 mv $SCRATCH_MNT/data/t6 $SCRATCH_MNT/data/n4/t2/t7/t4/t5
  58 mv $SCRATCH_MNT/data/n1/n2 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6
  59 mv $SCRATCH_MNT/data/n1 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6
  60 mv $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/t7 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n2
  61 mv $SCRATCH_MNT/data/t3 $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n2/t7
  62
  63 # Filesystem looks like:
  64 #
  65 # .                                                                   (ino 256)
  66 # |-- data/                                                           (ino 257)
  67 #       |-- n4/                                                       (ino 260)
  68 #            |-- t2/                                                  (ino 265)
  69 #                 |-- t7/                                             (ino 264)
  70 #                      |-- t4/                                        (ino 266)
  71 #                           |-- t5/                                   (ino 263)
  72 #                                |-- t6/                              (ino 261)
  73 #                                     |-- n1/                         (ino 258)
  74 #                                     |-- n2/                         (ino 259)
  75 #                                          |-- t7/                    (ino 262)
  76 #                                               |-- t3/               (ino 267)
  77 #
  78 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap1
  79
  80 # The sequence of directory rename operations below made the btrfs incremental
  81 # send implementation enter an infinite loop when building path strings. The
  82 # reason for this was the following:
  83 #
  84 # * While processing inode 262 it ended up orphanizing inode 264 (rename it to
  85 #   "/o264-6-0"). This is because the parent inode 265 has a dentry with name
  86 #   t7 in the parent snapshot that refers to inode 264, which is ahead of the
  87 #   current send progress (inode 262) and our inode 262 has the name t7 in
  88 #   the directory inode 265 in the send snapshot - so in order to rename inode
  89 #   262 to its new name/location, it orphanizes (renames) 264 before 264 is
  90 #   processed;
  91 #
  92 # * When it processes inode 264 it was not checking if it needed to delay its
  93 #   rename operation. This was incorrect because in the parent snapshot inode
  94 #   267 is a descendent of inode 264 and inode 267 is an ancestor of inode 264
  95 #   in the send snapshot, which means the rename of inode 264 must happen after
  96 #   inode 267 is renamed in order to avoid the infinite loops when building
  97 #   path strings that involved inodes 264 and 267;
  98 #
  99 # * As a consequence as soon as the send progress moved to inode 265, the
 100 #   following loop when building a path string for inode 264 happened:
 101 #
 102 #     start inode 264, send progress of 265 for example
 103 #     parent of 264 -> 267
 104 #     parent of 267 -> 262
 105 #     parent of 262 -> 259
 106 #     parent of 259 -> 261
 107 #     parent of 261 -> 263
 108 #     parent of 263 -> 266
 109 #     parent of 266 -> 264
 110 #       |--> back to first iteration while current path string length
 111 #            is <= PATH_MAX, and fail with -ENOMEM otherwise
 112 #
 113 mv $SCRATCH_MNT/data/n4/t2/t7/t4/t5/t6/n1 $SCRATCH_MNT/data/n4
 114 mv $SCRATCH_MNT/data/n4/t2 $SCRATCH_MNT/data/n4/n1
 115 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4/t5/t6/n2 $SCRATCH_MNT/data/n4/n1/t2
 116 mv $SCRATCH_MNT/data/n4/n1/t2/n2/t7/t3 $SCRATCH_MNT/data/n4/n1/t2
 117 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4/t5/t6 $SCRATCH_MNT/data/n4/n1/t2
 118 mv $SCRATCH_MNT/data/n4/n1/t2/t7/t4 $SCRATCH_MNT/data/n4/n1/t2/t6
 119 mv $SCRATCH_MNT/data/n4/n1/t2/t7 $SCRATCH_MNT/data/n4/n1/t2/t3
 120 mv $SCRATCH_MNT/data/n4/n1/t2/n2/t7 $SCRATCH_MNT/data/n4/n1/t2
 121
 122 # Filesystem now looks like:
 123 #
 124 # .                                                                   (ino 256)
 125 # |-- data/                                                           (ino 257)
 126 #       |-- n4/                                                       (ino 260)
 127 #            |-- n1/                                                  (ino 258)
 128 #                 |-- t2/                                             (ino 265)
 129 #                      |-- n2/                                        (ino 259)
 130 #                      |-- t3/                                        (ino 267)
 131 #                      |    |-- t7                                    (ino 264)
 132 #                      |
 133 #                      |-- t6/                                        (ino 261)
 134 #                      |    |-- t4/                                   (ino 266)
 135 #                      |         |-- t5/                              (ino 263)
 136 #                      |
 137 #                      |-- t7/                                        (ino 262)
 138 #
 139 _run_btrfs_util_prog subvolume snapshot -r $SCRATCH_MNT $SCRATCH_MNT/mysnap2
 140
 141 run_check $FSSUM_PROG -A -f -w $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
 142 run_check $FSSUM_PROG -A -f -w $send_files_dir/2.fssum \
 143         -x $SCRATCH_MNT/mysnap2/mysnap1 $SCRATCH_MNT/mysnap2
 144
 145 _run_btrfs_util_prog send -f $send_files_dir/1.snap $SCRATCH_MNT/mysnap1
 146 _run_btrfs_util_prog send -p $SCRATCH_MNT/mysnap1 -f $send_files_dir/2.snap \
 147         $SCRATCH_MNT/mysnap2
 148
 149 # Now recreate the filesystem by receiving both send streams and verify we get
 150 # the same content that the original filesystem had.
 151 _scratch_unmount
 152 _scratch_mkfs >>$seqres.full 2>&1
 153 _scratch_mount
 154
 155 _run_btrfs_util_prog receive -f $send_files_dir/1.snap $SCRATCH_MNT
 156 run_check $FSSUM_PROG -r $send_files_dir/1.fssum $SCRATCH_MNT/mysnap1
 157 _run_btrfs_util_prog receive -f $send_files_dir/2.snap $SCRATCH_MNT
 158 run_check $FSSUM_PROG -r $send_files_dir/2.fssum $SCRATCH_MNT/mysnap2
 159
 160 echo "Silence is golden"
 161 status=0
 162 exit