On Mon, Aug 08, 2022 at 12:18:58PM +0100, fdmanana@xxxxxxxxxx wrote:
> From: Filipe Manana <fdmanana@xxxxxxxx>
>
> Test that if we punch a hole adjacent to an existing hole, fsync the file
> and then power fail, the new hole exists after mounting again the
> filesystem.
>
> This currently fails on btrfs with kernels 5.18 and 5.19 when not using
> the "no-holes" feature. The "no-holes" feature is enabled by default at
> mkfs time starting with btrfs-progs 5.15, so to trigger the issue with
> btrfs-progs 5.15+ and kernel 5.18 or kernel 5.19, one must set
> "-O ^no-holes" in the MKFS_OPTIONS environment variable (part of the
> btrfs test matrix).
>
> The issue is fixed for btrfs with the following kernel patch:
>
> "btrfs: update generation of hole file extent item when merging holes"
CC btrfs list
>
> Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx>
> ---
> tests/generic/694 | 85 +++++++++++++++++++++++++++++++++++++++++++
> tests/generic/694.out | 15 ++++++++
> 2 files changed, 100 insertions(+)
> create mode 100755 tests/generic/694
> create mode 100644 tests/generic/694.out
>
> diff --git a/tests/generic/694 b/tests/generic/694
> new file mode 100755
> index 00000000..c034f914
> --- /dev/null
> +++ b/tests/generic/694
> @@ -0,0 +1,85 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2022 SUSE Linux Products GmbH. All Rights Reserved.
> +#
> +# FS QA Test 694
> +#
> +# Test that if we punch a hole adjacent to an existing hole, fsync the file and
> +# then power fail, the new hole exists after mounting again the filesystem.
Better to explain this's a known regression test at here.
And add _fixed_by_kernel_commit later, after that kernel patch is merged and
has a fixed commit id.
> +#
> +. ./common/preamble
> +_begin_fstest quick log punch
"auto" group?
> +
> +_cleanup()
> +{
> + _cleanup_flakey
> + cd /
> + rm -r -f $tmp.*
> +}
> +
> +# Import common functions.
> +. ./common/filter
> +. ./common/dmflakey
> +. ./common/punch
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
^^^^
This's just a reminder, please remove it.
> +_supported_fs generic
> +_require_scratch
> +_require_dm_target flakey
> +_require_xfs_io_command "fpunch"
> +_require_xfs_io_command "fiemap"
> +
> +_scratch_mkfs >>$seqres.full 2>&1
> +_require_metadata_journaling $SCRATCH_DEV
> +_init_flakey
> +_mount_flakey
> +
> +# Create our test file with the following layout:
> +#
> +# [0, 2M) - hole
> +# [2M, 10M) - extent
> +# [10M, 12M) - hole
> +$XFS_IO_PROG -f -c "truncate 12M" \
> + -c "pwrite -S 0xab 2M 8M" \
> + $SCRATCH_MNT/foobar | _filter_xfs_io
> +
> +# Persist everything, commit the filesystem's transaction.
> +sync
> +
> +# Now punch two holes in the file:
> +#
> +# 1) For the range [2M, 4M), which is adjacent to the existing hole in the range
> +# [0, 2M);
> +# 2) For the range [8M, 10M), which is adjacent to the existing hole in the
> +# range [10M, 12M).
> +#
> +# These operations start a new filesystem transaction.
> +# Then finally fsync the file.
> +$XFS_IO_PROG -c "fpunch 2M 2M" \
> + -c "fpunch 8M 2M" \
> + -c "fsync" $SCRATCH_MNT/foobar
Darrick added a new helper _require_congruent_file_oplen(), might worth
using it. Any thoughts?
> +
> +# Simulate a power failure and mount the filesystem to check that everything
> +# is in the same state as before the power failure.
> +_flakey_drop_and_remount
> +
> +# We expect the following file layout:
> +#
> +# [0, 4M) - hole
> +# [4M, 8M) - extent
> +# [8M, 12M) - hole
> +echo "File layout after power failure:"
> +$XFS_IO_PROG -c "fiemap -v" $SCRATCH_MNT/foobar | _filter_fiemap
> +
> +# When reading the file we expect to get the range [4M, 8M) filled with bytes
> +# that have a value of 0xab and 0x00 for anything outside that range.
> +echo "File content after power failure:"
> +od -A d -t x1 $SCRATCH_MNT/foobar
Can _hexdump in common/rc help ?
> +
> +_unmount_flakey
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/694.out b/tests/generic/694.out
> new file mode 100644
> index 00000000..f55212f3
> --- /dev/null
> +++ b/tests/generic/694.out
> @@ -0,0 +1,15 @@
> +QA output created by 694
> +wrote 8388608/8388608 bytes at offset 2097152
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +File layout after power failure:
> +0: [0..8191]: hole
> +1: [8192..16383]: data
> +2: [16384..24575]: hole
> +File content after power failure:
> +0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +*
> +4194304 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab
> +*
> +8388608 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> +*
> +12582912
> --
> 2.35.1
>
