FS/XFS testing framework
 help / color / mirror / Atom feed
From: "Yang Xu (Fujitsu)" <xuyang2018.jy@fujitsu.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: "fstests@vger.kernel.org" <fstests@vger.kernel.org>,
	"djwong@kernel.org" <djwong@kernel.org>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"tytso@mit.edu" <tytso@mit.edu>, "shr@fb.com" <shr@fb.com>
Subject: Re: [PATCH] generic/471: Remove this broken case
Date: Wed, 16 Aug 2023 14:58:10 +0000	[thread overview]
Message-ID: <9eadebb8-1bc7-1c19-ad3d-04b31271f8dc@fujitsu.com> (raw)
In-Reply-To: <CAL3q7H7C0mE9tBaipdYPYOCgBVYMTVKQ8=f90khTckt1CbBF4A@mail.gmail.com>

on  2023/08/15 18:44, Filipe Manana wrote:
> On Mon, Aug 14, 2023 at 4:04 PM Yang Xu <xuyang2018.jy@fujitsu.com> wrote:
>>
>> I remember this case fails on last year becuase of
>> kernel commit cae2de69 ("iomap: Add async buffered write support")
>> kernel commit 1aa91d9 ("xfs: Add async buffered write support").
>> as below:
>>       pwrite: Resource temporarily unavailable
>>       wrote 8388608/8388608 bytes at offset 0
>>       XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>>      -RWF_NOWAIT time is within limits.
>>      +pwrite: Resource temporarily unavailable
>>      +(standard_in) 1: syntax error
>>      +RWF_NOWAIT took  seconds
>>
>> So For async buffered write requests, the request will return -EAGAIN
> 
> I'm curious about this.
> 
> All the xfs_io pwrite calls are being done with Direct IO (-d)
> argument, so how does that explain the failure?

I am not understand async buffer write, but with the following 
discussion link[1] maybe explain this failure and explain why btrfs passed.
> 
>> if the ilock cannot be obtained immediately.
> 
> What is the ilock? That seems to be xfs specific.

yes, I guess it is xfs_ilock and they are xfs specific.
> 
> The test passes on btrfs and btrfs supports async buffered writes -
> but I'm still puzzled, because the test only does direct IO writes.
> Does xfs falls back from direct IO to buffered IO?
> 
>>
>> Here also a discussion[1] that seems generic/471 has been broken.
> 
> Well that discussion doesn't help me understand things. It mentions
> some other discussion, presumably with more details. Where's that
> other discussion?

I think the url that Jens mention should be this[1] when he reviewed
Stefan V7 patch for "io-uring/xfs: support async buffered writes".

[1]https://lkml.kernel.org/linux-fsdevel/ca60a7dc-b16d-d8ce-f56c-547b449da8c9@kernel.dk/ 


Best Regards
Yang Xu
> 
> Thanks.
> 
>>
>> Now, I met this problem in my linux distribution, then I found the above
>> discussion. IMO, remove this case is ok and then we can avoid to meet this
>> false report again.
>>
>> [1]https://lore.kernel.org/linux-xfs/b2865bd6-2346-8f4d-168b-17f06bbedbed@kernel.dk/
>> Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
>> ---
>>   tests/generic/471     | 67 -------------------------------------------
>>   tests/generic/471.out | 13 ---------
>>   2 files changed, 80 deletions(-)
>>   delete mode 100755 tests/generic/471
>>   delete mode 100644 tests/generic/471.out
>>
>> diff --git a/tests/generic/471 b/tests/generic/471
>> deleted file mode 100755
>> index fbd0b12a..00000000
>> --- a/tests/generic/471
>> +++ /dev/null
>> @@ -1,67 +0,0 @@
>> -#! /bin/bash
>> -# SPDX-License-Identifier: GPL-2.0
>> -# Copyright (c) 2017, SUSE Linux Products.  All Rights Reserved.
>> -#
>> -# FS QA Test No. 471
>> -#
>> -# write a file with RWF_NOWAIT and it would fail because there are no
>> -# blocks allocated. Create a file with direct I/O and re-write it
>> -# using RWF_NOWAIT. I/O should finish within 50 microsecods since
>> -# block allocations are already performed.
>> -#
>> -. ./common/preamble
>> -_begin_fstest auto quick rw
>> -
>> -# Import common functions.
>> -. ./common/populate
>> -. ./common/filter
>> -. ./common/attr
>> -
>> -# real QA test starts here
>> -_require_odirect
>> -_require_test
>> -_require_xfs_io_command pwrite -N
>> -
>> -# Remove reminiscence of previously run tests
>> -testdir=$TEST_DIR/$seq
>> -if [ -e $testdir ]; then
>> -       rm -Rf $testdir
>> -fi
>> -
>> -mkdir $testdir
>> -
>> -# Btrfs is a COW filesystem, so a RWF_NOWAIT write will always fail with -EAGAIN
>> -# when writing to a file range except if it's a NOCOW file and an extent for the
>> -# range already exists or if it's a COW file and preallocated/unwritten extent
>> -# exists in the target range. So to make sure that the last write succeeds on
>> -# all filesystems, use a NOCOW file on btrfs.
>> -if [ $FSTYP == "btrfs" ]; then
>> -       _require_chattr C
>> -       # Zoned btrfs does not support NOCOW
>> -       _require_non_zoned_device $TEST_DEV
>> -       touch $testdir/f1
>> -       $CHATTR_PROG +C $testdir/f1
>> -fi
>> -
>> -# Create a file with pwrite nowait (will fail with EAGAIN)
>> -$XFS_IO_PROG -f -d -c "pwrite -N -V 1 -b 1M 0 1M" $testdir/f1
>> -
>> -# Write the file without nowait
>> -$XFS_IO_PROG -f -d -c "pwrite -S 0xaa -W -w -V 1 -b 1M 0 8M" $testdir/f1 | _filter_xfs_io
>> -
>> -time_taken=`$XFS_IO_PROG -d -c "pwrite -S 0xbb -N -V 1 -b 1M 2M 1M" $testdir/f1 | awk '/^1/ {print $5}'`
>> -
>> -# RWF_NOWAIT should finish within a short period of time so we are choosing
>> -# a conservative value of 50 ms. Anything longer means it is waiting
>> -# for something in the kernel which would be a fail.
>> -if (( $(echo "$time_taken < 0.05" | bc -l) )); then
>> -       echo "RWF_NOWAIT time is within limits."
>> -else
>> -       echo "RWF_NOWAIT took $time_taken seconds"
>> -fi
>> -
>> -$XFS_IO_PROG -c "pread -v 0 8M" $testdir/f1 | _filter_xfs_io_unique
>> -
>> -# success, all done
>> -status=0
>> -exit
>> diff --git a/tests/generic/471.out b/tests/generic/471.out
>> deleted file mode 100644
>> index ab23272e..00000000
>> --- a/tests/generic/471.out
>> +++ /dev/null
>> @@ -1,13 +0,0 @@
>> -QA output created by 471
>> -pwrite: Resource temporarily unavailable
>> -wrote 8388608/8388608 bytes at offset 0
>> -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>> -RWF_NOWAIT time is within limits.
>> -00000000:  aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa  ................
>> -*
>> -00200000:  bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb  ................
>> -*
>> -00300000:  aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa  ................
>> -*
>> -read 8388608/8388608 bytes at offset 0
>> -XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>> --
>> 2.27.0
>>

  reply	other threads:[~2023-08-16 15:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-14 14:41 [PATCH] generic/471: Remove this broken case Yang Xu
2023-08-14 15:37 ` Darrick J. Wong
2023-08-14 21:40   ` Jens Axboe
2023-08-14 22:42 ` Bill O'Donnell
2023-08-15 10:44 ` Filipe Manana
2023-08-16 14:58   ` Yang Xu (Fujitsu) [this message]
2023-08-18 12:43     ` Zorro Lang
2023-08-19 16:25       ` Filipe Manana
2023-08-20  3:59         ` Zorro Lang
2023-08-21  5:39         ` Dave Chinner
2023-08-21 11:16           ` Filipe Manana
2023-08-21 14:59             ` Yang Xu (Fujitsu)
2023-08-24  2:33             ` Dave Chinner

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=9eadebb8-1bc7-1c19-ad3d-04b31271f8dc@fujitsu.com \
    --to=xuyang2018.jy@fujitsu.com \
    --cc=axboe@kernel.dk \
    --cc=djwong@kernel.org \
    --cc=fdmanana@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=shr@fb.com \
    --cc=tytso@mit.edu \
    /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