All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: djwong@kernel.org, zlang@redhat.com
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me,
	yangx.jy@fujitsu.com
Subject: [PATCH 3/3] xfs/182: fix spurious direct write failure
Date: Tue, 17 Jan 2023 16:42:44 -0800	[thread overview]
Message-ID: <167400102485.1914858.8399289411855614483.stgit@magnolia> (raw)
In-Reply-To: <167400102444.1914858.13132645140135239531.stgit@magnolia>

From: Darrick J. Wong <djwong@kernel.org>

This test has some weird behavior that causes regressions when fsdax and
reflink are enabled.  The goal of this test is to set a cow extent size
hint, perform some random directio writes, perform a directio rewrite of
the entire file, and make sure that the file content (and extent count)
are sane afterwards.

Most of the time, the random directio writes will never touch the
8388609th byte, though if they do randomly select that EOF block, they'd
end up extending the file by $real_blksz bytes and causing spurious test
failures.

Then, the rewrite does this:

pwrite -S 0x63 -b $real_blksz 0 $((filesize + 1))

Note that we previously set filesize=8388608, which means that we're
asking for a series of direct writes that fill the first 8388608 bytes
with 'c'.  The last write in the series becomes a single byte direct
write.  For regular file access mode, this last write will fail with
EINVAL, since block devices do not support byte granularity writes and
XFS does not fall back to the pagecache for unaligned direct wites.
Hence we never wrote the 8388609th byte of the file.

However, fsdax *does* allow byte-granularity direct writes, which means
that the single-byte write succeeds.  There is no EINVAL return code,
and the 8388609th byte of the file is now 'c' instead of 'a'.  As a
result, the md5 of file2 is different.

Since fsdax+reflink is the newcomer, amend the direct writes in this
test so that they always end at the 8388608th byte, since we were never
really testing that last byte anyway.  This makes the test behavior
consistent across both access modes.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/182     |    4 ++--
 tests/xfs/182.out |    1 -
 2 files changed, 2 insertions(+), 3 deletions(-)


diff --git a/tests/xfs/182 b/tests/xfs/182
index ec3f7dc026..696b933e60 100755
--- a/tests/xfs/182
+++ b/tests/xfs/182
@@ -55,9 +55,9 @@ md5sum $testdir/file2 | _filter_scratch
 
 echo "CoW and unmount"
 $XFS_IO_PROG -f -c "cowextsize" $testdir/file2 >> $seqres.full
-$XFS_IO_PROG -d -f -c "pwrite -R -S 0x63 -b $real_blksz 0 $((filesize + 1))" \
+$XFS_IO_PROG -d -f -c "pwrite -R -S 0x63 -b $real_blksz 0 $filesize" \
 	$testdir/file2 2>&1 >> $seqres.full | _filter_xfs_io_error
-$XFS_IO_PROG -d -f -c "pwrite -S 0x63 -b $real_blksz 0 $((filesize + 1))" \
+$XFS_IO_PROG -d -f -c "pwrite -S 0x63 -b $real_blksz 0 $filesize" \
 	$testdir/file2 2>&1 >> $seqres.full | _filter_xfs_io_error
 _scratch_cycle_mount
 
diff --git a/tests/xfs/182.out b/tests/xfs/182.out
index 41384437ad..8821bcd5bd 100644
--- a/tests/xfs/182.out
+++ b/tests/xfs/182.out
@@ -5,7 +5,6 @@ Compare files
 2909feb63a37b0e95fe5cfb7f274f7b1  SCRATCH_MNT/test-182/file1
 2909feb63a37b0e95fe5cfb7f274f7b1  SCRATCH_MNT/test-182/file2
 CoW and unmount
-pwrite: Invalid argument
 Compare files
 2909feb63a37b0e95fe5cfb7f274f7b1  SCRATCH_MNT/test-182/file1
 c6ba35da9f73ced20d7781a448cc11d4  SCRATCH_MNT/test-182/file2


  parent reply	other threads:[~2023-01-18  0:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18  0:41 [PATCHSET 0/3] fstests: fix dax+reflink tests Darrick J. Wong
2023-01-18  0:42 ` [PATCH 1/3] xfs: fix dax inode flag test failures Darrick J. Wong
2023-01-18  6:55   ` Xiao Yang
2023-01-18  0:42 ` [PATCH 2/3] xfs: fix reflink test failures when dax is enabled Darrick J. Wong
2023-01-18  5:10   ` Xiao Yang
2023-01-18  0:42 ` Darrick J. Wong [this message]
2023-01-18  5:13   ` [PATCH 3/3] xfs/182: fix spurious direct write failure Xiao Yang

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=167400102485.1914858.8399289411855614483.stgit@magnolia \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=linux-xfs@vger.kernel.org \
    --cc=yangx.jy@fujitsu.com \
    --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 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.