From: "Darrick J. Wong" <djwong@kernel.org>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: fstests <fstests@vger.kernel.org>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2 3/4] generic/676: Add a new shutdown recovery test
Date: Tue, 15 Mar 2022 09:55:14 -0700 [thread overview]
Message-ID: <20220315165514.GC8200@magnolia> (raw)
In-Reply-To: <3d8c4f7374e97ccee285474efd04b093afe3ee16.1647342932.git.riteshh@linux.ibm.com>
On Tue, Mar 15, 2022 at 07:58:58PM +0530, Ritesh Harjani wrote:
> In certain cases (it is noted with ext4 fast_commit feature) that, replay phase
> may not delete the right range of blocks (after sudden FS shutdown)
> due to some operations which depends on inode->i_size (which during replay of
> an inode with fast_commit could be 0 for sometime).
> This fstest is added to test for such scenarios for all generic fs.
>
> This test case is based on the test case shared via Xin Yin.
>
> Signed-off-by: Ritesh Harjani <riteshh@linux.ibm.com>
> ---
> tests/generic/676 | 72 +++++++++++++++++++++++++++++++++++++++++++
> tests/generic/676.out | 7 +++++
> 2 files changed, 79 insertions(+)
> create mode 100755 tests/generic/676
> create mode 100644 tests/generic/676.out
>
> diff --git a/tests/generic/676 b/tests/generic/676
> new file mode 100755
> index 00000000..315edcdf
> --- /dev/null
> +++ b/tests/generic/676
> @@ -0,0 +1,72 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2022 IBM Corporation. All Rights Reserved.
> +#
> +# FS QA Test 676
> +#
> +# This test with ext4 fast_commit feature w/o below patch missed to delete the right
> +# range during replay phase, since it depends upon inode->i_size (which might not be
> +# stable during replay phase, at least for ext4).
> +# 0b5b5a62b945a141: ext4: use ext4_ext_remove_space() for fast commit replay delete range
> +# (Based on test case shared by Xin Yin <yinxin.x@bytedance.com>)
> +#
> +
> +. ./common/preamble
> +_begin_fstest auto shutdown quick log recoveryloop
This isn't a looping recovery test. Maybe we should create a 'recovery'
group for tests that only run once? I think we already have a few
fstests like that.
> +
> +# Override the default cleanup function.
> +_cleanup()
> +{
> + cd /
> + rm -r -f $tmp.*
> + _scratch_unmount > /dev/null 2>&1
I think the test harness does this for you already, right?
> +}
> +
> +# Import common functions.
> +. ./common/filter
> +. ./common/punch
> +
> +# real QA test starts here
> +
> +# Modify as appropriate.
> +_supported_fs generic
> +_require_scratch
> +_require_xfs_io_command "fpunch"
> +_require_xfs_io_command "fzero"
> +_require_xfs_io_command "fiemap"
_require_scratch_shutdown
> +
> +t1=$SCRATCH_MNT/foo
> +t2=$SCRATCH_MNT/bar
> +
> +_scratch_mkfs > $seqres.full 2>&1
> +
> +_scratch_mount >> $seqres.full 2>&1
> +
> +bs=$(_get_block_size $SCRATCH_MNT)
_get_file_block_size, in case the file allocation unit isn't the same as
the fs blocksize? (e.g. bigalloc, xfs realtime, etc.)
--D
> +
> +# create and write data to t1
> +$XFS_IO_PROG -f -c "pwrite 0 $((100*$bs))" $t1 | _filter_xfs_io_numbers
> +
> +# fzero certain range in between with -k
> +$XFS_IO_PROG -c "fzero -k $((40*$bs)) $((20*$bs))" $t1
> +
> +# create and fsync a new file t2
> +$XFS_IO_PROG -f -c "fsync" $t2
> +
> +# fpunch within the i_size of a file
> +$XFS_IO_PROG -c "fpunch $((30*$bs)) $((20*$bs))" $t1
> +
> +# fsync t1 to trigger journal operation
> +$XFS_IO_PROG -c "fsync" $t1
> +
> +# shutdown FS now for replay journal to kick in next mount
> +_scratch_shutdown -v >> $seqres.full 2>&1
> +
> +_scratch_cycle_mount
> +
> +# check fiemap reported is valid or not
> +$XFS_IO_PROG -c "fiemap -v" $t1 | _filter_fiemap_flags $bs
> +
> +# success, all done
> +status=0
> +exit
> diff --git a/tests/generic/676.out b/tests/generic/676.out
> new file mode 100644
> index 00000000..78375940
> --- /dev/null
> +++ b/tests/generic/676.out
> @@ -0,0 +1,7 @@
> +QA output created by 676
> +wrote XXXX/XXXX bytes at offset XXXX
> +XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
> +0: [0..29]: none
> +1: [30..49]: hole
> +2: [50..59]: unwritten
> +3: [60..99]: nonelast
> --
> 2.31.1
>
next prev parent reply other threads:[~2022-03-15 16:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-15 14:28 [PATCHv2 0/4] generic: Add some tests around journal replay/recoveryloop Ritesh Harjani
2022-03-15 14:28 ` [PATCHv2 1/4] generic/468: Add another falloc test entry Ritesh Harjani
2022-03-15 16:51 ` Darrick J. Wong
2022-03-29 10:59 ` Ritesh Harjani
2022-03-15 14:28 ` [PATCHv2 2/4] common/punch: Add block_size argument to _filter_fiemap_** Ritesh Harjani
2022-03-15 14:28 ` [PATCHv2 3/4] generic/676: Add a new shutdown recovery test Ritesh Harjani
2022-03-15 16:55 ` Darrick J. Wong [this message]
2022-03-29 11:32 ` Ritesh Harjani
2022-03-31 9:49 ` Ritesh Harjani
2022-03-15 14:28 ` [PATCHv2 4/4] generic/677: Add a test to check unwritten extents tracking Ritesh Harjani
2022-03-15 16:56 ` Darrick J. Wong
2022-03-29 11:34 ` Ritesh Harjani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220315165514.GC8200@magnolia \
--to=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riteshh@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.