FS/XFS testing framework
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Anand Jain <anand.jain@oracle.com>,
	zlang@kernel.org, fstests@vger.kernel.org,
	linux-btrfs@vger.kernel.org, josef@toxicpanda.com,
	dsterba@suse.cz
Subject: Re: [PATCH 1/2] common/filter.btrfs: add a new _filter_snapshot
Date: Sat, 6 Apr 2024 08:14:41 +1030	[thread overview]
Message-ID: <006cd98d-1e4e-43e5-8f8d-88a8840232d7@gmx.com> (raw)
In-Reply-To: <20240405164643.GA634366@frogsfrogsfrogs>



在 2024/4/6 03:16, Darrick J. Wong 写道:
> On Fri, Apr 05, 2024 at 08:20:59PM +1030, Qu Wenruo wrote:
>>
>>
>> 在 2024/4/5 19:55, Anand Jain 写道:
>>>
>>>
>>> On 4/5/24 16:52, Qu Wenruo wrote:
>>>>
>>>>
>>>> 在 2024/4/5 19:15, Anand Jain 写道:
>>>>> As the newer btrfs-progs have changed the output of the command
>>>>> "btrfs subvolume snapshot," which is part of the golden output,
>>>>> create a helper filter to ensure the test cases pass on older
>>>>> btrfs-progs.
>>>>>
>>>>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>>>>
>>>> Can we stop the golden output filter game?
>>>>
>>>>   From day one I'm not a big fan of the golden output idea.
>>>> For snapshot/subvolume creation, we don't really care about what the
>>>> output is, we only care if there is any error (which would come from
>>>> stderr).
>>>>
>>>> In that case, why not just redirect the stdout to null?
>>>>
>>>> To me, if we really care something from the stdout, we can still save it
>>>> and let bash/awk/grep to process it, like what we did for various test
>>>> cases, and then save the result to seqres.full.
>
> That sums up what output filters do; I don't understand the objection
> here...

Well, I have seen quite some cases where we need to verify the speed of
scrub to be inside a reasonable range.

In that case, I do not thing any simple filter is good enough.

And for a lot of cases, we just want to make sure the IO finishes, in
that case simply redirect to seqres.full looks more reasonable other
than call _xfs_io_filter.

But I guess this is to personal tastes.

>
>>>>
>>>
>>> This is a bug-fix patch; it's not a good idea to change the concept of
>>> fstests' golden output. Perhaps an RFC patch about your idea can help
>>> to discuss and achieve consensus.
>>
>> Even as bug-fix, a simple redirect to seqres.full and remove the
>> corresponding line from golden output is very valid to me.
>>
>> In fact, introducing a filter looks very over-engineered in this
>> particular case.
>
> ...but having said that , I also dislike overfixation on golden output.
> Patches welcome. ;)

Sure, one simple patch for evaluation.

Thanks,
Qu
>
> --D
>
>>
>>>
>>> Thanks, Anand
>>>
>>>
>>>> Thanks,
>>>> Qu
>>>>> ---
>>>>>    common/filter.btrfs | 9 +++++++++
>>>>>    tests/btrfs/001     | 3 ++-
>>>>>    tests/btrfs/152     | 6 +++---
>>>>>    tests/btrfs/168     | 6 +++---
>>>>>    tests/btrfs/202     | 4 ++--
>>>>>    tests/btrfs/302     | 4 ++--
>>>>>    6 files changed, 21 insertions(+), 11 deletions(-)
>>>>>
>>>>> diff --git a/common/filter.btrfs b/common/filter.btrfs
>>>>> index 9ef9676175c9..415ed6dfd088 100644
>>>>> --- a/common/filter.btrfs
>>>>> +++ b/common/filter.btrfs
>>>>> @@ -156,5 +156,14 @@ _filter_device_add()
>>>>>
>>>>>    }
>>>>>
>>>>> +_filter_snapshot()
>>>>> +{
>>>>> +    # btrfs-progs commit 5f87b467a9e7 ("btrfs-progs: subvolume:
>>>>> output the
>>>>> +    # prompt line only when the ioctl succeeded") changed the output
>>>>> for
>>>>> +    # btrfs subvolume snapshot, ensure that the latest fstests
>>>>> continue to
>>>>> +    # work on older btrfs-progs without the above commit.
>>>>> +    _filter_scratch | sed -e "s/Create a/Create/g"
>>>>> +}
>>>>> +
>>>>>    # make sure this script returns success
>>>>>    /bin/true
>>>>> diff --git a/tests/btrfs/001 b/tests/btrfs/001
>>>>> index 6c2639990373..cfcf2ade4590 100755
>>>>> --- a/tests/btrfs/001
>>>>> +++ b/tests/btrfs/001
>>>>> @@ -26,7 +26,8 @@ dd if=/dev/zero of=$SCRATCH_MNT/foo bs=1M count=1
>>>>> &> /dev/null
>>>>>    echo "List root dir"
>>>>>    ls $SCRATCH_MNT
>>>>>    echo "Creating snapshot of root dir"
>>>>> -$BTRFS_UTIL_PROG subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap |
>>>>> _filter_scratch
>>>>> +$BTRFS_UTIL_PROG subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap | \
>>>>> +                            _filter_snapshot
>>>>>    echo "List root dir after snapshot"
>>>>>    ls $SCRATCH_MNT
>>>>>    echo "List snapshot dir"
>>>>> diff --git a/tests/btrfs/152 b/tests/btrfs/152
>>>>> index 75f576c3cfca..b89fe361e84e 100755
>>>>> --- a/tests/btrfs/152
>>>>> +++ b/tests/btrfs/152
>>>>> @@ -11,7 +11,7 @@
>>>>>    _begin_fstest auto quick metadata qgroup send
>>>>>
>>>>>    # Import common functions.
>>>>> -. ./common/filter
>>>>> +. ./common/filter.btrfs
>>>>>
>>>>>    # real QA test starts here
>>>>>    _supported_fs btrfs
>>>>> @@ -32,9 +32,9 @@ touch $SCRATCH_MNT/subvol{1,2}/foo
>>>>>
>>>>>    # Create base snapshots and send them
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/subvol1 \
>>>>> -    $SCRATCH_MNT/subvol1/.snapshots/1 | _filter_scratch
>>>>> +    $SCRATCH_MNT/subvol1/.snapshots/1 | _filter_snapshot
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/subvol2 \
>>>>> -    $SCRATCH_MNT/subvol2/.snapshots/1 | _filter_scratch
>>>>> +    $SCRATCH_MNT/subvol2/.snapshots/1 | _filter_snapshot
>>>>>    for recv in recv1_1 recv1_2 recv2_1 recv2_2; do
>>>>>        $BTRFS_UTIL_PROG send $SCRATCH_MNT/subvol1/.snapshots/1 2>
>>>>> /dev/null | \
>>>>>            $BTRFS_UTIL_PROG receive $SCRATCH_MNT/${recv} |
>>>>> _filter_scratch
>>>>> diff --git a/tests/btrfs/168 b/tests/btrfs/168
>>>>> index acc58b51ee39..78bc9b8f81bb 100755
>>>>> --- a/tests/btrfs/168
>>>>> +++ b/tests/btrfs/168
>>>>> @@ -20,7 +20,7 @@ _cleanup()
>>>>>    }
>>>>>
>>>>>    # Import common functions.
>>>>> -. ./common/filter
>>>>> +. ./common/filter.btrfs
>>>>>
>>>>>    # real QA test starts here
>>>>>    _supported_fs btrfs
>>>>> @@ -74,7 +74,7 @@ $BTRFS_UTIL_PROG property set $SCRATCH_MNT/sv1 ro
>>>>> false
>>>>>    # Create a snapshot of the subvolume, to be used later as the
>>>>> parent snapshot
>>>>>    # for an incremental send operation.
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/sv1
>>>>> $SCRATCH_MNT/snap1 \
>>>>> -    | _filter_scratch
>>>>> +                            | _filter_snapshot
>>>>>
>>>>>    # First do a full send of this snapshot.
>>>>>    $FSSUM_PROG -A -f -w $send_files_dir/snap1.fssum $SCRATCH_MNT/snap1
>>>>> @@ -88,7 +88,7 @@ $XFS_IO_PROG -c "pwrite -S 0x19 4K 8K"
>>>>> $SCRATCH_MNT/sv1/baz >>$seqres.full
>>>>>    # Create a second snapshot of the subvolume, to be used later as
>>>>> the send
>>>>>    # snapshot of an incremental send operation.
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/sv1
>>>>> $SCRATCH_MNT/snap2 \
>>>>> -    | _filter_scratch
>>>>> +                            | _filter_snapshot
>>>>>
>>>>>    # Temporarily turn the second snapshot to read-write mode and then
>>>>> open a file
>>>>>    # descriptor on its foo file.
>>>>> diff --git a/tests/btrfs/202 b/tests/btrfs/202
>>>>> index 5f0429f18bf9..57ecbe47c0bb 100755
>>>>> --- a/tests/btrfs/202
>>>>> +++ b/tests/btrfs/202
>>>>> @@ -8,7 +8,7 @@
>>>>>    . ./common/preamble
>>>>>    _begin_fstest auto quick subvol snapshot
>>>>>
>>>>> -. ./common/filter
>>>>> +. ./common/filter.btrfs
>>>>>
>>>>>    _supported_fs btrfs
>>>>>    _require_scratch
>>>>> @@ -28,7 +28,7 @@ _scratch_mount
>>>>>    $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a | _filter_scratch
>>>>>    $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/a/b | _filter_scratch
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot $SCRATCH_MNT/a $SCRATCH_MNT/c \
>>>>> -    | _filter_scratch
>>>>> +                            | _filter_snapshot
>>>>>
>>>>>    # Need the dummy entry created so that we get the invalid removal
>>>>> when we rmdir
>>>>>    ls $SCRATCH_MNT/c/b
>>>>> diff --git a/tests/btrfs/302 b/tests/btrfs/302
>>>>> index f3e6044b5251..52d712ac50de 100755
>>>>> --- a/tests/btrfs/302
>>>>> +++ b/tests/btrfs/302
>>>>> @@ -15,7 +15,7 @@
>>>>>    . ./common/preamble
>>>>>    _begin_fstest auto quick snapshot subvol
>>>>>
>>>>> -. ./common/filter
>>>>> +. ./common/filter.btrfs
>>>>>
>>>>>    _supported_fs btrfs
>>>>>    _require_scratch
>>>>> @@ -46,7 +46,7 @@ $FSSUM_PROG -A -f -w $fssum_file $SCRATCH_MNT/subvol
>>>>>    # Now create a snapshot of the subvolume and make it accessible
>>>>> from within the
>>>>>    # subvolume.
>>>>>    $BTRFS_UTIL_PROG subvolume snapshot -r $SCRATCH_MNT/subvol \
>>>>> -         $SCRATCH_MNT/subvol/snap | _filter_scratch
>>>>> +                 $SCRATCH_MNT/subvol/snap | _filter_snapshot
>>>>>
>>>>>    # Now unmount and mount again the fs. We want to verify we are able
>>>>> to read all
>>>>>    # metadata for the snapshot from disk (no IO failures, etc).
>>>
>>
>

  reply	other threads:[~2024-04-05 21:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-05  8:45 [PATCH 0/2] fstests: btrfs: subvolume snapshot fix golden output Anand Jain
2024-04-05  8:45 ` [PATCH 1/2] common/filter.btrfs: add a new _filter_snapshot Anand Jain
2024-04-05  8:52   ` Qu Wenruo
2024-04-05  9:25     ` Anand Jain
2024-04-05  9:50       ` Qu Wenruo
2024-04-05 16:46         ` Darrick J. Wong
2024-04-05 21:44           ` Qu Wenruo [this message]
2024-04-05  8:45 ` [PATCH 2/2] btrfs: create snapshot fix golden output Anand Jain
2024-04-05 22:05 ` [PATCH 0/2] fstests: btrfs: subvolume " Qu Wenruo
2024-04-08  4:30   ` Anand Jain
2024-04-08  4:32 ` [PATCH v2] common/filter.btrfs: introduce _filter_snapshot Anand Jain
2024-04-08  6:12   ` David Disseldorp
2024-04-08  8:24   ` Qu Wenruo
2024-04-09  0:57     ` Anand Jain
2024-04-09  1:28       ` Qu Wenruo

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=006cd98d-1e4e-43e5-8f8d-88a8840232d7@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=anand.jain@oracle.com \
    --cc=djwong@kernel.org \
    --cc=dsterba@suse.cz \
    --cc=fstests@vger.kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=zlang@kernel.org \
    /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