public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Filipe Manana <fdmanana@kernel.org>
Cc: fstests@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v3 03/10] btrfs: create a helper function, check_fsid(), to verify the tempfsid
Date: Wed, 28 Feb 2024 15:06:22 +0530	[thread overview]
Message-ID: <e4416120-e682-4a43-b79e-a930838bb64e@oracle.com> (raw)
In-Reply-To: <CAL3q7H4EdcvJm4jAD+5-zm-WVAoaHhyy-9Q_1-P5pOWk_f6m=w@mail.gmail.com>



> function should do the require for everything it needs that may not be
> available.
> It's doing for the inspect-internal command, but it's missing a:
> 
> _require_btrfs_sysfs_fsid


Yes, it did. Actually, check_fsid() would need the following to
cover all the prerequisites.

  _require_btrfs_fs_sysfs
  _require_btrfs_fs_feature temp_fsid
  _require_btrfs_fs_feature metadata_uuid
  _require_btrfs_command inspect-internal dump-super


I already have v4 with what you just suggested, I am going to send it.


 > Instead this is being called for every test case that calls this new
 > helper function, when those requirements should be hidden from the
 > tests themselves.

However, I am a bit skeptical if we should move all prerequisites to
the helpers or only some major prerequisites.

Because returning _notrun() in the middle of the testcase is something
I am not sure is better than at the beginning of the testcase (I do not
have a specific example where it is not a good idea, though).

And, theoretically, figuring out if the test case would run/_notrun()
will be complicated.

Next, we shall end up checking the _require..() multiple times in
a test case, though one time is enough (the test cases 311, 312,
313 call check_fsid() two times).

Furthermore, it will inconsistent, as a lot of command wraps are
already missing such a requirement; I'm not sure if we shall ever
achieve consistency across fstests (For example: _cp_reflink()
missing _require_cp_reflink).

Lastly, if there are duplicating prerequisites across the helper
functions, then we call _require..() many more times (for example:
313 will call mkfs_clone() and check_fsid() two times, which
means we would verify the following three times in a testcase.

  _require_btrfs_fs_feature metadata_uuid
  _require_btrfs_command inspect-internal dump-super


So, how about prerequisites of the newer functions as comments
above the function to be copied into the test case?

Thanks, Anand

  reply	other threads:[~2024-02-28  9:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-24 16:43 [PATCH v3 00/10] btrfs: functional test cases for tempfsid Anand Jain
2024-02-24 16:43 ` [PATCH v3 01/10] assign SCRATCH_DEV_POOL to an array Anand Jain
2024-02-24 16:43 ` [PATCH v3 02/10] btrfs: introduce tempfsid test group Anand Jain
2024-02-24 16:43 ` [PATCH v3 03/10] btrfs: create a helper function, check_fsid(), to verify the tempfsid Anand Jain
2024-02-26 11:47   ` Filipe Manana
2024-02-28  9:36     ` Anand Jain [this message]
2024-02-28 10:28       ` Filipe Manana
2024-02-29  1:50         ` Anand Jain
2024-02-24 16:43 ` [PATCH v3 04/10] btrfs: verify that subvolume mounts are unaffected by tempfsid Anand Jain
2024-02-26 11:49   ` Filipe Manana
2024-02-24 16:43 ` [PATCH v3 05/10] btrfs: check if cloned device mounts with tempfsid Anand Jain
2024-02-26 11:55   ` Filipe Manana
2024-02-29  1:49     ` Anand Jain
2024-02-24 16:43 ` [PATCH v3 06/10] btrfs: test case prerequisite _require_btrfs_mkfs_uuid_option Anand Jain
2024-02-24 16:43 ` [PATCH v3 07/10] btrfs: introduce helper for creating cloned devices with mkfs Anand Jain
2024-02-26 11:57   ` Filipe Manana
2024-02-24 16:43 ` [PATCH v3 08/10] btrfs: verify tempfsid clones using mkfs Anand Jain
2024-02-26 11:59   ` Filipe Manana
2024-02-24 16:43 ` [PATCH v3 09/10] btrfs: validate send-receive operation with tempfsid Anand Jain
2024-02-26 12:06   ` Filipe Manana
2024-02-29  1:49     ` Anand Jain
2024-02-24 16:43 ` [PATCH v3 10/10] btrfs: test tempfsid with device add, seed, and balance Anand Jain
2024-02-26 12:08   ` Filipe Manana
2024-02-29  1:49     ` 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=e4416120-e682-4a43-b79e-a930838bb64e@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=fdmanana@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.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