FS/XFS testing framework
 help / color / mirror / Atom feed
From: Xiao Yang <yangx.jy@fujitsu.com>
To: "Darrick J. Wong" <djwong@kernel.org>, <zlang@redhat.com>
Cc: <linux-xfs@vger.kernel.org>, <fstests@vger.kernel.org>, <guan@eryu.me>
Subject: Re: [PATCH 3/3] xfs/182: fix spurious direct write failure
Date: Wed, 18 Jan 2023 13:13:36 +0800	[thread overview]
Message-ID: <dcb548b0-0050-77a7-7b66-a483cb4c8046@fujitsu.com> (raw)
In-Reply-To: <167400102485.1914858.8399289411855614483.stgit@magnolia>

Hi Darrick,

It looks good to me. It actually fixed the failure of xfs/182 with 
enabled fsdax and reflink.
Reviewed-by: Xiao Yang <yangx.jy@fujitsu.com>

Best Regards,
Xiao Yang

On 2023/1/18 8:42, Darrick J. Wong wrote:
> 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
> 

      reply	other threads:[~2023-01-18  5:13 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 ` [PATCH 3/3] xfs/182: fix spurious direct write failure Darrick J. Wong
2023-01-18  5:13   ` Xiao Yang [this message]

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=dcb548b0-0050-77a7-7b66-a483cb4c8046@fujitsu.com \
    --to=yangx.jy@fujitsu.com \
    --cc=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=guan@eryu.me \
    --cc=linux-xfs@vger.kernel.org \
    --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