linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Ritesh Harjani <ritesh.list@gmail.com>
Cc: Catherine Hoang <catherine.hoang@oracle.com>,
	linux-xfs@vger.kernel.org, fstests@vger.kernel.org,
	john.g.garry@oracle.com
Subject: Re: [PATCH v2 6/6] generic: various atomic write tests with scsi_debug
Date: Tue, 20 May 2025 19:30:52 -0700	[thread overview]
Message-ID: <20250521023052.GC9705@frogsfrogsfrogs> (raw)
In-Reply-To: <8734czwkqd.fsf@gmail.com>

On Tue, May 20, 2025 at 05:35:30PM +0530, Ritesh Harjani wrote:
> Catherine Hoang <catherine.hoang@oracle.com> writes:
> 
> > From: "Darrick J. Wong" <djwong@kernel.org>
> >
> > Simple tests of various atomic write requests and a (simulated) hardware
> > device.
> >
> > Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> > Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
> > ---
> >  common/atomicwrites    |  10 +++
> >  tests/generic/1222     |  86 +++++++++++++++++++++++++
> >  tests/generic/1222.out |  10 +++
> >  tests/generic/1223     |  66 +++++++++++++++++++
> >  tests/generic/1223.out |   9 +++
> >  tests/generic/1224     | 140 +++++++++++++++++++++++++++++++++++++++++
> >  tests/generic/1224.out |  17 +++++
> >  tests/xfs/1216         |  67 ++++++++++++++++++++
> >  tests/xfs/1216.out     |   9 +++
> >  tests/xfs/1217         |  70 +++++++++++++++++++++
> >  tests/xfs/1217.out     |   3 +
> >  tests/xfs/1218         |  59 +++++++++++++++++
> >  tests/xfs/1218.out     |  15 +++++
> >  13 files changed, 561 insertions(+)
> >  create mode 100755 tests/generic/1222
> >  create mode 100644 tests/generic/1222.out
> >  create mode 100755 tests/generic/1223
> >  create mode 100644 tests/generic/1223.out
> >  create mode 100644 tests/generic/1224
> >  create mode 100644 tests/generic/1224.out
> >  create mode 100755 tests/xfs/1216
> >  create mode 100644 tests/xfs/1216.out
> >  create mode 100755 tests/xfs/1217
> >  create mode 100644 tests/xfs/1217.out
> >  create mode 100644 tests/xfs/1218
> >  create mode 100644 tests/xfs/1218.out
> >
> > diff --git a/common/atomicwrites b/common/atomicwrites
> > index 391bb6f6..c75c3d39 100644
> > --- a/common/atomicwrites
> > +++ b/common/atomicwrites
> > @@ -115,3 +115,13 @@ _test_atomic_file_writes()
> >      $XFS_IO_PROG -dc "pwrite -A -D -V1 -b $bsize 1 $bsize" $testfile 2>> $seqres.full && \
> >          echo "atomic write requires offset to be aligned to bsize"
> >  }
> > +
> > +_simple_atomic_write() {
> > +	local pos=$1
> > +	local count=$2
> > +	local file=$3
> > +	local directio=$4
> > +
> > +	echo "testing pos=$pos count=$count file=$file directio=$directio" >> $seqres.full
> > +	$XFS_IO_PROG $directio -c "pwrite -b $count -V 1 -A -D $pos $count" $file >> $seqres.full
> > +}
> > diff --git a/tests/generic/1222 b/tests/generic/1222
> > new file mode 100755
> > index 00000000..9d02bd70
> > --- /dev/null
> > +++ b/tests/generic/1222
> > @@ -0,0 +1,86 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2025 Oracle.  All Rights Reserved.
> > +#
> > +# FS QA Test 1222
> > +#
> > +# Validate multi-fsblock atomic write support with simulated hardware support
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto quick rw atomicwrites
> > +
> > +. ./common/scsi_debug
> > +. ./common/atomicwrites
> > +
> > +_cleanup()
> > +{
> > +	_scratch_unmount &>/dev/null
> > +	_put_scsi_debug_dev &>/dev/null
> > +	cd /
> > +	rm -r -f $tmp.*
> > +}
> > +
> > +_require_scsi_debug
> > +_require_scratch_nocheck
> > +# Format something so that ./check doesn't freak out
> > +_scratch_mkfs >> $seqres.full
> > +
> > +# 512b logical/physical sectors, 512M size, atomic writes enabled
> > +dev=$(_get_scsi_debug_dev 512 512 0 512 "atomic_wr=1")
> > +test -b "$dev" || _notrun "could not create atomic writes scsi_debug device"
> > +
> > +export SCRATCH_DEV=$dev
> > +unset USE_EXTERNAL
> > +
> > +_require_scratch_write_atomic
> > +_require_atomic_write_test_commands
> 
> Is it possible to allow pwrite -A to be tested on $SCRATCH_MNT rather
> than on TEST_MNT? For e.g. 
> 
> What happens when TEST_DEV is not atomic write capable? Then this test
> won't run even though we are passing scsi_debug which supports atomic writes.

Hrmmmm.  Maybe we need an open-coded version of the "make sure the
xfs_io commands are present" checks without actually doing live testing
of the $TEST_DIR since we're creating a scsi-debug with atomic write
capability anyway.

> > +
> > +echo "scsi_debug atomic write properties" >> $seqres.full
> > +$XFS_IO_PROG -c "statx -r -m $STATX_WRITE_ATOMIC" $SCRATCH_DEV >> $seqres.full
> > +
> > +_scratch_mkfs >> $seqres.full
> > +_scratch_mount
> > +test "$FSTYP" = "xfs" && _xfs_force_bdev data $SCRATCH_MNT
> > +
> > +testfile=$SCRATCH_MNT/testfile
> > +touch $testfile
> > +
> > +echo "filesystem atomic write properties" >> $seqres.full
> > +$XFS_IO_PROG -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile >> $seqres.full
> > +
> > +sector_size=$(blockdev --getss $SCRATCH_DEV)
> > +min_awu=$(_get_atomic_write_unit_min $testfile)
> > +max_awu=$(_get_atomic_write_unit_max $testfile)
> > +
> > +$XFS_IO_PROG -f -c "falloc 0 $((max_awu * 2))" -c fsync $testfile
> > +
> > +# try outside the advertised sizes
> > +echo "two EINVAL for unsupported sizes"
> > +min_i=$((min_awu / 2))
> > +_simple_atomic_write $min_i $min_i $testfile -d
> > +max_i=$((max_awu * 2))
> > +_simple_atomic_write $max_i $max_i $testfile -d
> > +
> > +# try all of the advertised sizes
> > +echo "all should work"
> > +for ((i = min_awu; i <= max_awu; i *= 2)); do
> > +	$XFS_IO_PROG -f -c "falloc 0 $((max_awu * 2))" -c fsync $testfile
> > +	_test_atomic_file_writes $i $testfile
> > +	_simple_atomic_write $i $i $testfile -d
> > +done
> > +
> > +# does not support buffered io
> > +echo "one EOPNOTSUPP for buffered atomic"
> > +_simple_atomic_write 0 $min_awu $testfile
> > +
> > +# does not support unaligned directio
> > +echo "one EINVAL for unaligned directio"
> > +_simple_atomic_write $sector_size $min_awu $testfile -d
> > +
> > +_scratch_unmount
> > +_put_scsi_debug_dev
> > +
> > +# success, all done
> > +echo Silence is golden
> > +status=0
> > +exit
> > diff --git a/tests/generic/1222.out b/tests/generic/1222.out
> > new file mode 100644
> > index 00000000..158b52fa
> > --- /dev/null
> > +++ b/tests/generic/1222.out
> > @@ -0,0 +1,10 @@
> > +QA output created by 1222
> > +two EINVAL for unsupported sizes
> > +pwrite: Invalid argument
> > +pwrite: Invalid argument
> > +all should work
> > +one EOPNOTSUPP for buffered atomic
> > +pwrite: Operation not supported
> > +one EINVAL for unaligned directio
> > +pwrite: Invalid argument
> > +Silence is golden
> > diff --git a/tests/generic/1223 b/tests/generic/1223
> > new file mode 100755
> > index 00000000..8a77386e
> > --- /dev/null
> > +++ b/tests/generic/1223
> > @@ -0,0 +1,66 @@
> > +#! /bin/bash
> > +# SPDX-License-Identifier: GPL-2.0
> > +# Copyright (c) 2025 Oracle.  All Rights Reserved.
> > +#
> > +# FS QA Test 1223
> > +#
> > +# Validate multi-fsblock atomic write support with or without hw support
> > +#
> > +. ./common/preamble
> > +_begin_fstest auto quick rw atomicwrites
> > +
> > +. ./common/atomicwrites
> > +
> > +_require_scratch
> > +_require_atomic_write_test_commands
> > +
> > +echo "scratch device atomic write properties" >> $seqres.full
> > +$XFS_IO_PROG -c "statx -r -m $STATX_WRITE_ATOMIC" $SCRATCH_DEV >> $seqres.full
> > +
> > +_scratch_mkfs >> $seqres.full
> > +_scratch_mount
> > +test "$FSTYP" = "xfs" && _xfs_force_bdev data $SCRATCH_MNT
> > +
> > +testfile=$SCRATCH_MNT/testfile
> > +touch $testfile
> > +
> > +echo "filesystem atomic write properties" >> $seqres.full
> > +$XFS_IO_PROG -c "statx -r -m $STATX_WRITE_ATOMIC" $testfile >> $seqres.full
> > +
> > +sector_size=$(blockdev --getss $SCRATCH_DEV)
> > +min_awu=$(_get_atomic_write_unit_min $testfile)
> > +max_awu=$(_get_atomic_write_unit_max $testfile)
> > +
> > +$XFS_IO_PROG -f -c "falloc 0 $((max_awu * 2))" -c fsync $testfile
> > +
> > +# try outside the advertised sizes
> > +echo "two EINVAL for unsupported sizes"
> > +min_i=$((min_awu / 2))
> > +_simple_atomic_write $min_i $min_i $testfile -d
> > +max_i=$((max_awu * 2))
> > +_simple_atomic_write $max_i $max_i $testfile -d
> > +
> > +# try all of the advertised sizes
> > +for ((i = min_awu; i <= max_awu; i *= 2)); do
> 
> If the kernel we are testing on doesn't have SW XFS atomic write patches
> and if the scratch device does not support HW atomic write, then this
> could cause an infinite loop, right? Since both min_awu and max_awu can
> come out to be 0? 

<nod> This should _notrun if max_awu is zero.

> > +	$XFS_IO_PROG -f -c "falloc 0 $((max_awu * 2))" -c fsync $testfile
> > +	_test_atomic_file_writes $i $testfile
> > +	_simple_atomic_write $i $i $testfile -d
> > +done
> > +
> > +# does not support buffered io
> > +echo "one EOPNOTSUPP for buffered atomic"
> > +_simple_atomic_write 0 $min_awu $testfile
> > +
> > +# does not support unaligned directio
> > +echo "one EINVAL for unaligned directio"
> > +if [ $sector_size -lt $min_awu ]; then
> > +	_simple_atomic_write $sector_size $min_awu $testfile -d
> > +else
> > +	# not supported, so fake the output
> > +	echo "pwrite: Invalid argument"
> > +fi
> > +
> > +# success, all done
> > +echo Silence is golden
> > +status=0
> > +exit
> > diff --git a/tests/generic/1223.out b/tests/generic/1223.out
> > new file mode 100644
> > index 00000000..edf5bd71
> > --- /dev/null
> > +++ b/tests/generic/1223.out
> > @@ -0,0 +1,9 @@
> > +QA output created by 1223
> > +two EINVAL for unsupported sizes
> > +pwrite: Invalid argument
> > +pwrite: Invalid argument
> > +one EOPNOTSUPP for buffered atomic
> > +pwrite: Operation not supported
> > +one EINVAL for unaligned directio
> > +pwrite: Invalid argument
> > +Silence is golden
> 
> 
> Will continue reviewing from g/1224 and will let you know if I
> have any comments.

Ok.  Thanks for reviewing! :)

--D

  reply	other threads:[~2025-05-21  2:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-20  1:33 [PATCH v2 0/6] atomic writes tests Catherine Hoang
2025-05-20  1:33 ` [PATCH v2 1/6] generic/765: fix a few issues Catherine Hoang
2025-05-20  2:10   ` Ritesh Harjani
2025-05-22 10:14   ` Ojaswin Mujoo
2025-05-20  1:33 ` [PATCH v2 2/6] generic/765: adjust various things Catherine Hoang
2025-05-22 10:14   ` Ojaswin Mujoo
2025-05-20  1:33 ` [PATCH v2 3/6] generic/765: move common atomic write code to a library file Catherine Hoang
2025-05-22 10:26   ` Ojaswin Mujoo
2025-05-20  1:33 ` [PATCH v2 4/6] common/atomicwrites: adjust a few more things Catherine Hoang
2025-05-22 10:37   ` Ojaswin Mujoo
2025-05-20  1:33 ` [PATCH v2 5/6] common/atomicwrites: fix _require_scratch_write_atomic Catherine Hoang
2025-05-20  2:14   ` Ritesh Harjani
2025-05-20  1:34 ` [PATCH v2 6/6] generic: various atomic write tests with scsi_debug Catherine Hoang
2025-05-20 12:05   ` Ritesh Harjani
2025-05-21  2:30     ` Darrick J. Wong [this message]
2025-05-22 10:33       ` Ojaswin Mujoo
2025-05-28 22:00         ` Darrick J. Wong
2025-05-21  4:43   ` Ritesh Harjani
2025-05-22 10:53   ` Ojaswin Mujoo

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=20250521023052.GC9705@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=catherine.hoang@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=john.g.garry@oracle.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ritesh.list@gmail.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;
as well as URLs for NNTP newsgroup(s).