From: John Garry <john.g.garry@oracle.com>
To: Ojaswin Mujoo <ojaswin@linux.ibm.com>,
Zorro Lang <zlang@redhat.com>,
fstests@vger.kernel.org
Cc: Ritesh Harjani <ritesh.list@gmail.com>,
djwong@kernel.org, tytso@mit.edu, linux-xfs@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH v4 09/11] ext4: Atomic writes stress test for bigalloc using fio crc verifier
Date: Tue, 12 Aug 2025 09:08:59 +0100 [thread overview]
Message-ID: <62ae0bd7-51f2-454d-a005-9a3673059d1b@oracle.com> (raw)
In-Reply-To: <210979d189d43165fa792101cf2f4eb8ef02bc98.1754833177.git.ojaswin@linux.ibm.com>
On 10/08/2025 14:42, Ojaswin Mujoo wrote:
> From: "Ritesh Harjani (IBM)" <ritesh.list@gmail.com>
>
> We brute force all possible blocksize & clustersize combinations on
> a bigalloc filesystem for stressing atomic write using fio data crc
> verifier.
you seem to run mkfs per block size. Why not just mkfs for largest
blocksize once, which will support all block sizes?
> We run nproc * $LOAD_FACTOR threads in parallel writing to
> a single $SCRATCH_MNT/test-file. With atomic writes this test ensures
> that we never see the mix of data contents from different threads on
> a given bsrange.
>
> This test might do overlapping atomic writes but that should be okay
> since overlapping parallel hardware atomic writes don't cause tearing as
> long as io size is the same for all writes.
Please mention that serializing racing writes is not guaranteed for
RWF_ATOMIC, and that NVMe and SCSI provide this guarantee as an
inseparable feature to power-fail atomicity.
Please also mention that the value is that we test that we split no bios
or only generate a single bio per write syscall.
>
> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> ---
> tests/ext4/061 | 130 +++++++++++++++++++++++++++++++++++++++++++++
> tests/ext4/061.out | 2 +
> 2 files changed, 132 insertions(+)
> create mode 100755 tests/ext4/061
> create mode 100644 tests/ext4/061.out
>
> diff --git a/tests/ext4/061 b/tests/ext4/061
> new file mode 100755
> index 00000000..a0e49249
> --- /dev/null
> +++ b/tests/ext4/061
> @@ -0,0 +1,130 @@
> +#! /bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2025 IBM Corporation. All Rights Reserved.
> +#
> +# FS QA Test 061
> +#
> +# Brute force all possible blocksize clustersize combination on a bigalloc
> +# filesystem for stressing atomic write using fio data crc verifier. We run
> +# nproc * 2 * $LOAD_FACTOR threads in parallel writing to a single
> +# $SCRATCH_MNT/test-file. With fio aio-dio atomic write this test ensures that
> +# we should never see the mix of data contents from different threads for any
> +# given fio blocksize.
> +#
> +
> +. ./common/preamble
> +. ./common/atomicwrites
> +
> +_begin_fstest auto rw stress atomicwrites
> +
> +_require_scratch_write_atomic
> +_require_aiodio
do you require fio with a certain version somewhere?
> +
> +FIO_LOAD=$(($(nproc) * 2 * LOAD_FACTOR))
> +SIZE=$((100*1024*1024))
> +fiobsize=4096
> +
> +# Calculate fsblocksize as per bdev atomic write units.
> +bdev_awu_min=$(_get_atomic_write_unit_min $SCRATCH_DEV)
> +bdev_awu_max=$(_get_atomic_write_unit_max $SCRATCH_DEV)
> +fsblocksize=$(_max 4096 "$bdev_awu_min")
> +
> +function create_fio_configs()
> +{
> + create_fio_aw_config
> + create_fio_verify_config
> +}
> +
> +function create_fio_verify_config()
> +{
> +cat >$fio_verify_config <<EOF
> + [aio-dio-aw-verify]
> + direct=1
> + ioengine=libaio
> + rw=randwrite
it prob makes sense to just have read, but I guess with verify_only=1
that this makes no difference
> + bs=$fiobsize
> + fallocate=native
> + filename=$SCRATCH_MNT/test-file
> + size=$SIZE
> + iodepth=$FIO_LOAD
> + numjobs=$FIO_LOAD
> + atomic=1
> + group_reporting=1
> +
> + verify_only=1
> + verify_state_save=0
> + verify=crc32c
> + verify_fatal=1
> + verify_write_sequence=0
> +EOF
> +}
> +
> +function create_fio_aw_config()
> +{
> +cat >$fio_aw_config <<EOF
> + [aio-dio-aw]
> + direct=1
> + ioengine=libaio
> + rw=randwrite
> + bs=$fiobsize
> + fallocate=native
> + filename=$SCRATCH_MNT/test-file
> + size=$SIZE
> + iodepth=$FIO_LOAD
> + numjobs=$FIO_LOAD
> + group_reporting=1
> + atomic=1
> +
> + verify_state_save=0
> + verify=crc32c
> + do_verify=0
> +
> +EOF
> +}
> +
> +# Let's create a sample fio config to check whether fio supports all options.
> +fio_aw_config=$tmp.aw.fio
> +fio_verify_config=$tmp.verify.fio
> +fio_out=$tmp.fio.out
> +
> +create_fio_configs
> +_require_fio $fio_aw_config
> +
> +for ((fsblocksize=$fsblocksize; fsblocksize <= $(_get_page_size); fsblocksize = $fsblocksize << 1)); do
> + # cluster sizes above 16 x blocksize are experimental so avoid them
> + # Also, cap cluster size at 128kb to keep it reasonable for large
> + # blocks size
> + fs_max_clustersize=$(_min $((16 * fsblocksize)) "$bdev_awu_max" $((128 * 1024)))
> +
> + for ((fsclustersize=$fsblocksize; fsclustersize <= $fs_max_clustersize; fsclustersize = $fsclustersize << 1)); do
> + for ((fiobsize = $fsblocksize; fiobsize <= $fsclustersize; fiobsize = $fiobsize << 1)); do
> + MKFS_OPTIONS="-O bigalloc -b $fsblocksize -C $fsclustersize"
this is quite heavy indentation. Maybe the below steps can be put into a
separate routine (to make the code more readable).
> + _scratch_mkfs_ext4 >> $seqres.full 2>&1 || continue
> + if _try_scratch_mount >> $seqres.full 2>&1; then
> + echo "== FIO test for fsblocksize=$fsblocksize fsclustersize=$fsclustersize fiobsize=$fiobsize ==" >> $seqres.full
> +
> + touch $SCRATCH_MNT/f1
> + create_fio_configs
> +
> + cat $fio_aw_config >> $seqres.full
> + echo >> $seqres.full
> + cat $fio_verify_config >> $seqres.full
> +
> + $FIO_PROG $fio_aw_config >> $seqres.full
> + ret1=$?
> +
> + $FIO_PROG $fio_verify_config >> $seqres.full
> + ret2=$?
> +
> + _scratch_unmount
> +
> + [[ $ret1 -eq 0 && $ret2 -eq 0 ]] || _fail "fio with atomic write failed"
> + fi
> + done
> + done
> +done
> +
> +# success, all done
> +echo Silence is golden
> +status=0
> +exit
> diff --git a/tests/ext4/061.out b/tests/ext4/061.out
> new file mode 100644
> index 00000000..273be9e0
> --- /dev/null
> +++ b/tests/ext4/061.out
> @@ -0,0 +1,2 @@
> +QA output created by 061
> +Silence is golden
next prev parent reply other threads:[~2025-08-12 8:09 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-10 13:41 [PATCH v4 00/11] Add more tests for multi fs block atomic writes Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 01/11] common/rc: Add _min() and _max() helpers Ojaswin Mujoo
2025-08-13 12:20 ` David Laight
2025-08-21 10:35 ` Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 02/11] common/rc: Add a helper to run fsx on a given file Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 03/11] ltp/fsx.c: Add atomic writes support to fsx Ojaswin Mujoo
2025-08-13 13:42 ` John Garry
2025-08-21 9:45 ` Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 04/11] generic: Add atomic write test using fio crc check verifier Ojaswin Mujoo
2025-08-12 17:16 ` Darrick J. Wong
2025-08-13 13:39 ` John Garry
2025-08-21 8:42 ` Ojaswin Mujoo
2025-08-21 9:24 ` John Garry
2025-08-21 12:18 ` Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 05/11] generic: Add atomic write test using fio verify on file mixed mappings Ojaswin Mujoo
2025-08-12 17:16 ` Darrick J. Wong
2025-08-10 13:41 ` [PATCH v4 06/11] generic: Add atomic write multi-fsblock O_[D]SYNC tests Ojaswin Mujoo
2025-08-11 15:29 ` Darrick J. Wong
2025-08-10 13:41 ` [PATCH v4 07/11] generic: Stress fsx with atomic writes enabled Ojaswin Mujoo
2025-08-12 17:18 ` Darrick J. Wong
2025-08-13 5:45 ` Ojaswin Mujoo
2025-08-10 13:41 ` [PATCH v4 08/11] generic: Add sudden shutdown tests for multi block atomic writes Ojaswin Mujoo
2025-08-10 13:42 ` [PATCH v4 09/11] ext4: Atomic writes stress test for bigalloc using fio crc verifier Ojaswin Mujoo
2025-08-12 8:08 ` John Garry [this message]
2025-08-13 7:08 ` Ojaswin Mujoo
2025-08-13 7:33 ` John Garry
2025-08-21 8:29 ` Ojaswin Mujoo
2025-08-10 13:42 ` [PATCH v4 10/11] ext4: Atomic writes test for bigalloc using fio crc verifier on multiple files Ojaswin Mujoo
2025-08-13 13:45 ` John Garry
2025-08-21 8:28 ` Ojaswin Mujoo
2025-08-21 9:28 ` John Garry
2025-08-21 12:19 ` Ojaswin Mujoo
2025-08-10 13:42 ` [PATCH v4 11/11] ext4: Atomic write test for extent split across leaf nodes Ojaswin Mujoo
2025-08-12 17:19 ` Darrick J. Wong
2025-08-13 5:45 ` Ojaswin Mujoo
2025-08-13 13:54 ` John Garry
2025-08-21 8:25 ` Ojaswin Mujoo
2025-08-21 9:23 ` John Garry
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=62ae0bd7-51f2-454d-a005-9a3673059d1b@oracle.com \
--to=john.g.garry@oracle.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=tytso@mit.edu \
--cc=zlang@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox