From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 1/2] btrfs-progs: tests: Filter output for run_check_stdout
Date: Thu, 9 Apr 2020 17:52:04 +0200 [thread overview]
Message-ID: <20200409155204.GD5920@twin.jikos.cz> (raw)
In-Reply-To: <20200407071845.29428-2-wqu@suse.com>
On Tue, Apr 07, 2020 at 03:18:44PM +0800, Qu Wenruo wrote:
> Since run_check_stdout() can insert INSTRUMENT for all btrfs related
> programs, which could easily pollute the stdout, any caller of
> run_check_stdout() should do proper filter.
>
> The following callers are affected:
> - misc/004
> Filter the output of "btrfs ins min-dev-size"
>
> - misc/009
> - misc/013
> - misc/024
> They are all calling "btrfs ins rootid", so introduce get_subvolid()
> function to grab the subvolid properly.
>
> - misc/031
> Loose the filter for "btrfs qgroup show". No need for "tail -n 1".
>
> So we still have the same coverage, but now these tests won't cause
> false alert if we insert INSTRUMENT for all btrfs commands.
>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
> tests/common | 13 ++++++++++++
> tests/misc-tests/004-shrink-fs/test.sh | 11 ++++++++--
> .../009-subvolume-sync-must-wait/test.sh | 2 +-
> .../013-subvolume-sync-crash/test.sh | 2 +-
> .../024-inspect-internal-rootid/test.sh | 21 +++++++------------
> .../031-qgroup-parent-child-relation/test.sh | 4 ++--
> 6 files changed, 33 insertions(+), 20 deletions(-)
>
> diff --git a/tests/common b/tests/common
> index 71661e950db0..f8fc3cfd8b4f 100644
> --- a/tests/common
> +++ b/tests/common
> @@ -169,6 +169,9 @@ run_check()
>
> # same as run_check but the stderr+stdout output is duplicated on stdout and
> # can be processed further
> +#
> +# NOTE: If this function is called on btrfs related command, caller should
> +# filter the output, as INSTRUMENT can easily pollute the output.
> run_check_stdout()
> {
> local spec
> @@ -636,6 +639,16 @@ check_min_kernel_version()
> return 0
> }
>
> +# Get subvolume id for specified path
> +get_subvolid()
> +{
> + # run_check_stdout may have INSTRUMENT pollating the output,
> + # need to filter the output.
> + run_check_stdout "$TOP/btrfs" inspect-internal rootid "$1" | \
> + grep -e "^[[:digit:]]\+$"
This does not seem much better, now it's specific to the commands and
calling the commands directly in new tests will make it fail.
If we find another command where the extra output must be filtered,
another helper. The instrument-tool specific filtering is IMHO fixed in
one place and future proof.
I want to avoid adding yet another test coding style exception like "for
inspect-internal you must use this helper", we have already enough like
new tests not using the mount/umount helpers or opencoding other
existing helpers.
My idea is to let people write tests in a natural way and adapt the
instrumentation tools as we know what problems they could cause.
next prev parent reply other threads:[~2020-04-09 15:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 7:18 [PATCH v3 0/2] btrfs-progs: tests: Enahance INSTRUMENT coverage Qu Wenruo
2020-04-07 7:18 ` [PATCH v3 1/2] btrfs-progs: tests: Filter output for run_check_stdout Qu Wenruo
2020-04-09 15:52 ` David Sterba [this message]
2020-04-10 0:25 ` Qu Wenruo
2020-04-20 23:09 ` David Sterba
2020-04-07 7:18 ` [PATCH v3 2/2] btrfs-progs: tests: Introduce expand_command() to inject aruguments more accurately 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=20200409155204.GD5920@twin.jikos.cz \
--to=dsterba@suse.cz \
--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;
as well as URLs for NNTP newsgroup(s).