FS/XFS testing framework
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Qu Wenruo <wqu@suse.com>,
	linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Cc: Filipe Manana <fdmanana@kernel.org>
Subject: Re: [PATCH] fstests: btrfs/226: use nodatasum mount option to prevent false alerts
Date: Thu, 6 Feb 2025 10:13:28 +0800	[thread overview]
Message-ID: <e24e430c-73f8-4e18-be07-624581864de7@oracle.com> (raw)
In-Reply-To: <6b66d881e152296eab70acc19991d9a611aefde6.1738792721.git.wqu@suse.com>

On 6/2/25 05:58, Qu Wenruo wrote:
> [BUG]
> With recent kernel patch "btrfs: always fallback to buffered write if the
> inode requires checksum", the test case btrfs/226 will fail with the
> following error:
> 
> FSTYP         -- btrfs
> PLATFORM      -- Linux/x86_64 btrfs-vm 6.13.0-rc6-custom+ #209 SMP PREEMPT_DYNAMIC Fri Jan 24 17:23:03 ACDT 2025
> MKFS_OPTIONS  -- /dev/mapper/test-scratch1
> MOUNT_OPTIONS -- /dev/mapper/test-scratch1 /mnt/scratch
> 
> btrfs/226 1s ... - output mismatch (see /home/adam/xfstests/results//btrfs/226.out.bad)
>      --- tests/btrfs/226.out	2024-04-12 14:04:03.080000035 +0930
>      +++ /home/adam/xfstests/results//btrfs/226.out.bad	2025-02-06 08:23:42.564298585 +1030
>      @@ -39,14 +39,11 @@
>       Testing write against prealloc extent at eof
>       wrote 65536/65536 bytes at offset 0
>       XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>      -wrote 65536/65536 bytes at offset 65536
>      -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>      +pwrite: Resource temporarily unavailable
>       File after write:
>      ...
>      (Run 'diff -u /home/adam/xfstests/tests/btrfs/226.out /home/adam/xfstests/results//btrfs/226.out.bad'  to see the entire diff)
> Ran: btrfs/226
> Failures: btrfs/226
> Failed 1 of 1 tests
> 
> [CAUSE]
> That kernel patch makes btrfs to always fallback to buffered IO if the
> target inode requires data checksum.
> 
> This is to avoid more deadly problems of mismatched data checksum.
> 
> But this also means, for inodes with data checksum, RWF_NOWAIT will
> always fail, because we will wait writing back the page cache, thus
> breaking the RWF_NOWAIT requirement.
> 
> [FIX]
> Update the test case to utilize nodatasum mount option, so that the
> direct-IO will not fallback to buffered ones unconditionally.
> 
> Reported-by: Filipe Manana <fdmanana@kernel.org>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   tests/btrfs/226 | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/btrfs/226 b/tests/btrfs/226
> index 70275d0aa2d8..359813c4f394 100755
> --- a/tests/btrfs/226
> +++ b/tests/btrfs/226
> @@ -21,7 +21,12 @@ _require_xfs_io_command falloc -k
>   _require_xfs_io_command fpunch
>   
>   _scratch_mkfs >>$seqres.full 2>&1
> -_scratch_mount
> +
> +# This test involves RWF_NOWAIT direct IOs, but for inodes with data checksum,
> +# btrfs will fall back to buffered IO unconditionally to prevent data checksum
> +# mimsatch, and that will break RWF_NOWAIT with -EAGAIN.
> +# So here we have to go with nodatasum mount option.
> +_scratch_mount -o nodatasum
>   


Looks good.
Reviewed-by: Anand Jain <anand.jain@oracle.com>


Thx.
>   # Test a write against COW file/extent - should fail with -EAGAIN. Disable the
>   # NOCOW attribute of the file just in case MOUNT_OPTIONS has "-o nodatacow".


  reply	other threads:[~2025-02-06  2:13 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-05 21:58 [PATCH] fstests: btrfs/226: use nodatasum mount option to prevent false alerts Qu Wenruo
2025-02-06  2:13 ` Anand Jain [this message]
2025-02-06 12:10 ` Filipe Manana
2025-02-06 13:11   ` Anand Jain

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=e24e430c-73f8-4e18-be07-624581864de7@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=fdmanana@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.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