From: "Theodore Ts'o" <tytso@mit.edu>
To: Zorro Lang <zlang@redhat.com>
Cc: Jeremy Bongio <bongiojp@gmail.com>,
linux-ext4@vger.kernel.org, fstests@vger.kernel.org,
"Darrick J . Wong" <djwong@kernel.org>
Subject: Re: [PATCH v5] ext4/056: add a check to make sure ext4 uuid ioctls get/set during fsstress.
Date: Wed, 20 Jul 2022 07:42:25 -0400 [thread overview]
Message-ID: <YtfqIVEi7g4fFpqU@mit.edu> (raw)
In-Reply-To: <20220720100949.dttc5qbmy4qziz65@zlang-mailbox>
On Wed, Jul 20, 2022 at 06:09:49PM +0800, Zorro Lang wrote:
> On Tue, Jul 19, 2022 at 05:02:56PM -0700, Jeremy Bongio wrote:
> > +# Override the default cleanup function.
> > +_cleanup()
> > +{
> > + cd /
> > + rm -r -f $tmp.*
> > + kill -9 $fsstress_pid 2>/dev/null;
> > + wait $fsstress_pid > /dev/null 2>&1
>
> I think "wait" is enough. With this change, it's good to me.
The kill -9 is needed, because otherwise the test will run for a
**very** long time. The reason for it is because of the -n 999999 in
fstress_args:
> > +# Begin fsstress while modifying UUID
> > +fsstress_args=$(_scale_fsstress_args -d $SCRATCH_MNT -p 15 -n 999999)
> > +$FSSTRESS_PROG $fsstress_args > /dev/null 2>&1 &
> > +fsstress_pid=$!
We could adjust the number of loops to a more reasonable number, but
then test becomes less reliable, since depending on the storage device
(e.g., cheap USB thumb drive found in the checkout counter at a
convenience store, vs. a high-end NVMe SSD) and the overall speed of
the system, a different number of loops will be needed.
Given that we're *only* using the fsstress as an antogonist while we
are changing the UUID of the file system 20 times, killing the
fsstress once we're done with the UUID runs is sufficient, I would
argue.
Also, Jeremy, it looks like you haven't updated your xfstests-dev
repository in a few weeks. Since you started this project, ext4/056
has been assigned, and there has been some new helper programs added
which caused patch conflicts in src/Makefile and in .gitignore. They
were pretty trivial to fix up the patch conflicts (which I've done in
my xfstests-dev tree), but it's best practice to rebase on top of
origin/for-next and re-test just to make sure there haven't been some
major change in the fstests common scripts that might catch your test
out.
Also, feel free to add my:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Cheers,
- Ted
next prev parent reply other threads:[~2022-07-20 11:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-20 0:02 [PATCH v5] ext4/056: add a check to make sure ext4 uuid ioctls get/set during fsstress Jeremy Bongio
2022-07-20 10:09 ` Zorro Lang
2022-07-20 11:42 ` Theodore Ts'o [this message]
2022-07-20 15:06 ` Zorro Lang
2022-07-20 15:30 ` Theodore Ts'o
2022-07-20 17:16 ` Jeremy Bongio
-- strict thread matches above, loose matches on Subject: below --
2022-07-19 23:44 Jeremy Bongio
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=YtfqIVEi7g4fFpqU@mit.edu \
--to=tytso@mit.edu \
--cc=bongiojp@gmail.com \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=zlang@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.