On Thu, May 22, 2025 at 04:03:42PM +0530, Ojaswin Mujoo wrote: > On Tue, May 20, 2025 at 07:30:52PM -0700, Darrick J. Wong wrote: > > On Tue, May 20, 2025 at 05:35:30PM +0530, Ritesh Harjani wrote: > > > Catherine Hoang <catherine.hoang@xxxxxxxxxx> writes: > > > > > > > From: "Darrick J. Wong" <djwong@xxxxxxxxxx> > > <snip> > > > > + 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. > > I think it might be better to finally have a _require_scratch_xfs_io_command() > and hence a _require_scratch_atomic_write_commands. This can avoid the > open coding as well as future proof it for similar features. <comes back from vacation> /me looks at what _require_xfs_io_command actually does with the output: echo $testio | grep -q "not found" && \ _notrun "xfs_io $command $param_checked support is missing" echo $testio | grep -q "Operation not supported\|Inappropriate ioctl" && \ _notrun "xfs_io $command $param_checked failed (old kernel/wrong fs?)" echo $testio | grep -q "Invalid" && \ _notrun "xfs_io $command $param_checked failed (old kernel/wrong fs/bad args?)" echo $testio | grep -q "foreign file active" && \ _notrun "xfs_io $command $param_checked not supported on $FSTYP" echo $testio | grep -q "Function not implemented" && \ _notrun "xfs_io $command $param_checked support is missing (missing syscall?)" echo $testio | grep -q "unknown flag" && \ _notrun "xfs_io $command $param_checked support is missing (unknown flag)" Aha, so it skips the test for EOPNOTSUPP and EINVAL after trying to write 4k. Yay, an incohesive function that implies that it's looking to see if xfs_io recognizes a (sub)command, but then does more than that and actually requires that the kernel and the test filesystem support it too. <groan> So I guess either the one test that uses scsi-debug has to do its own grepping of the xfs_io -c 'help pwrite' output to look for atomic write support, or turn on scsi_debug, mount it, and do something awful like: TEST_DIR=/some/path _require_xfs_io_command pwrite -A Any takers? --D > > > > > > + > > > > +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 >
