Re: [PATCH v2] generic: test fsync after punching hole adjacent to an existing hole

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



On Thu, Sep 01, 2022 at 05:10:09PM +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"
> 
> Signed-off-by: Filipe Manana <fdmanana@xxxxxxxx>
> ---
> 
> v2: Added kernel commit tag (now that's merged in Linus' tree),
>     added auto group, added the new odd _require_congruent_file_oplen
>     requirement.

This version looks good to me, I don't have more review points.

Reviewed-by: Zorro Lang <zlang@xxxxxxxxxx>

> 
>  tests/generic/695     | 91 +++++++++++++++++++++++++++++++++++++++++++
>  tests/generic/695.out | 15 +++++++
>  2 files changed, 106 insertions(+)
>  create mode 100755 tests/generic/695
>  create mode 100644 tests/generic/695.out
> 
> diff --git a/tests/generic/695 b/tests/generic/695
> new file mode 100755
> index 00000000..b46e35cf
> --- /dev/null
> +++ b/tests/generic/695
> @@ -0,0 +1,91 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2022 SUSE Linux Products GmbH. All Rights Reserved.
> +#
> +# FS QA Test 695
> +#
> +# 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 is motivated by a regression on btrfs, fixed by the commit mentioned
> +# below, when not using the no-holes feature (which is enabled by default since
> +# btrfs-progs 5.15).
> +#
> +. ./common/preamble
> +_begin_fstest auto quick log punch
> +
> +_cleanup()
> +{
> +	_cleanup_flakey
> +	cd /
> +	rm -r -f $tmp.*
> +}
> +
> +. ./common/filter
> +. ./common/dmflakey
> +. ./common/punch
> +
> +_supported_fs generic
> +_fixed_by_kernel_commit e6e3dec6c3c288 \
> +        "btrfs: update generation of hole file extent item when merging holes"
> +_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
> +
> +# We punch 2M holes and require extent allocations to align to 2M in fiemap
> +# results.
> +_require_congruent_file_oplen $SCRATCH_MNT $((2 * 1024 * 1024))
> +
> +# 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
> +
> +# 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:"
> +_hexdump $SCRATCH_MNT/foobar
> +
> +_unmount_flakey
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/695.out b/tests/generic/695.out
> new file mode 100644
> index 00000000..447ef5cf
> --- /dev/null
> +++ b/tests/generic/695.out
> @@ -0,0 +1,15 @@
> +QA output created by 695
> +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:
> +000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
> +*
> +400000 ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab ab  >................<
> +*
> +800000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >................<
> +*
> +c00000
> -- 
> 2.35.1
> 




[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux