btrfs-progs: fsck-tests: fix an image which has incorrect super dev item

[CI FAILURE]
With Mark's incoming fsck enhancement on super block device item, it
exposed the following fs corruption on an existing image dump:

  restoring image keyed_data_ref_with_reloc_leaf.img
  ====== RUN CHECK /home/runner/work/btrfs-progs/btrfs-progs/btrfs check ./keyed_data_ref_with_reloc_leaf.img.restored
  [1/8] checking log skipped (none written)
  [2/8] checking root items
  [3/8] checking extents
  device 1's bytes_used was 55181312 in tree but 59375616 in superblock
  ERROR: errors found in extent allocation tree or chunk allocation
  [4/8] checking free space cache
  [5/8] checking fs roots
  [6/8] checking only csums items (without verifying data)
  [7/8] checking root refs
  [8/8] checking quota groups skipped (not enabled on this FS)
  Opening filesystem to check...
  Checking filesystem on ./keyed_data_ref_with_reloc_leaf.img.restored
  UUID: ca3568a3-d9d8-4901-b4dd-b180a437a07f
  found 1175552 bytes used, error(s) found
  total csum bytes: 512
  total tree bytes: 651264
  total fs tree bytes: 606208
  total extent tree bytes: 16384
  btree space waste bytes: 291631
  file data blocks allocated: 67633152
   referenced 1048576

[CAUSE]
The image has the following device item in the super block:

  dev_item.uuid		5a1c9f96-b581-4fd3-a73a-5cfd789c3c84
  dev_item.fsid		ca3568a3-d9d8-4901-b4dd-b180a437a07f [match]
  dev_item.type		0
  dev_item.total_bytes	67108864
  dev_item.bytes_used	59375616

Meanwhile the tree dump shows the following device item in the chunk
tree:

	item 0 key (DEV_ITEMS DEV_ITEM 1) itemoff 3897 itemsize 98
		devid 1 total_bytes 67108864 bytes_used 55181312
		io_align 4096 io_width 4096 sector_size 4096 type 0

The bytes_used value does not match and triggered the fsck failure.

The root cause of such a mismatch is that, there was a bug in the kernel
that resulted incorrect byte_used number.
The kernel bug is fixed by commit: ce7213c70c37 ("Btrfs: fix wrong device
bytes_used in the super block").

However that fix doesn't have any fixes tag, thus not automatically
backported to older stable kernels.

And the image seems to be created by an older stable kernel, thus
missing the fix and caused the above mismatch.

[FIX]
Re-generate the image with the latest kernel so that the mismatch won't
happen.

Furthermore for future updates, here is the needed steps to create the
image.

- Modify the kernel btrfs module to commit transaction more frequently
  The idea is to replace the btrfs_end_transaction_throttle() call
  inside the while() loop of relocate_block_group().

  So that every time a tree block is relocated, the fs will be
  committed.

- Use the following script to populate the fs with log-writes
  This requries CONFIG_DM_LOG_WRITES to be enabled.

```

dev_src="/dev/test/scratch1"
dev_log="/dev/test/log"
dev="/dev/mapper/log"
mnt="/mnt/btrfs/"
table="0 $(blockdev --getsz $dev_src) log-writes $dev_src $dev_log"

fail()
{
	echo "!!! FAILED !!!"
	exit 1
}

umount $dev &> /dev/null
umount $mnt &> /dev/null

dmsetup create log --table "$table" || fail
mkfs.btrfs -b 1G -n 4k -f -m single $dev
mount $dev $mnt

xfs_io -f -c "pwrite 0 512k" $mnt/src > /dev/null
sync

for ((i = 0; i < 128; i++)); do
	xfs_io -f -c "reflink $mnt/src $(($i * 4096)) $(($i * 4096)) 4K" $mnt/file1 > /dev/null || fail
done
for ((i = 0; i < 128; i++)); do
	xfs_io -f -c "pwrite 0 2k" $mnt/inline_$i > /dev/null || fail
done
sync
dmsetup message log 0 mark init
btrfs balance start -m $mnt
umount $mnt
dmsetup remove log
```

- Replay the log and run "btrfs dump-tree -t extent" for each fua
  Use the log-writes tool (https://github.com/josefbacik/log-writes.git)
  to replay the log.
  And there will be one with the following contents for the data extent
  item, with mixed keyed and shared backref.

          item 22 key (13631488 EXTENT_ITEM 524288) itemoff 3161 itemsize 108
                refs 180 gen 9 flags DATA
                (178 0xdfb591fbbf5f519) extent data backref root FS_TREE objectid 258 offset 0 count 77
                (178 0xdfb591fa80d95ea) extent data backref root FS_TREE objectid 257 offset 0 count 1
                (184 0x151e000) shared data backref parent 22142976 count 51
                (184 0x512000) shared data backref parent 5316608 count 51

- Take the image of that fs

This image has one extra benefit, that it exposed a bug in the older
lowmem code where shared backref number is not correctly skipped, thus
this image will also act as a regression test.

Signed-off-by: Qu Wenruo <[email protected]>

Author: adam900710