FS/XFS testing framework
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Filipe Manana <fdmanana@kernel.org>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH] fstests: btrfs/226: use nodatasum mount option to prevent false alerts
Date: Thu, 6 Feb 2025 21:11:56 +0800	[thread overview]
Message-ID: <68aa436b-4ddd-4ee7-ad5a-8eca55aae176@oracle.com> (raw)
In-Reply-To: <CAL3q7H74oD=fL9rRJVdQhONhyApOFDUFt=tcES_0=DcsQbiVGQ@mail.gmail.com>

On 6/2/25 20:10, Filipe Manana wrote:
> On Wed, Feb 5, 2025 at 9:59 PM Qu Wenruo <wqu@suse.com> 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,
> 
> involves -> exercises
> 
>> +# btrfs will fall back to buffered IO unconditionally to prevent data checksum
>> +# mimsatch, and that will break RWF_NOWAIT with -EAGAIN.
> 
> mimsatch -> mismatch
> 
>> +# So here we have to go with nodatasum mount option.
> 
> The whole text could be shorter and clear:
> 
> # RWF_NOWAIT only works with direct IO, which requires an inode with
> nodatasum (otherwise it falls back to buffered IO).
> 
> Otherwise it looks fine, so:
> 
> Reviewed-by: Filipe Manana <fdmanana@suse.com>
> 

Fixed. Applied to for-next at https://github.com/asj/fstests.git

Thx.

> Thanks.
> 
>> +_scratch_mount -o nodatasum
>>
>>   # 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".
>> --
>> 2.48.1
>>


      reply	other threads:[~2025-02-06 13:12 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
2025-02-06 12:10 ` Filipe Manana
2025-02-06 13:11   ` Anand Jain [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=68aa436b-4ddd-4ee7-ad5a-8eca55aae176@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