From: "Theodore Ts'o" <tytso@mit.edu>
To: Eryu Guan <guan@eryu.me>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic: test which tries to exercise AIO/DIO into unwritten space
Date: Sun, 7 Mar 2021 18:11:37 -0500 [thread overview]
Message-ID: <YEVdqb9kcOV004ZO@mit.edu> (raw)
In-Reply-To: <YET+QSgT3e+R/yzO@desktop>
On Mon, Mar 08, 2021 at 12:24:33AM +0800, Eryu Guan wrote:
> > +trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
>
> Better to trap a _cleanup function, even we only do "rm -f $tmp.*" in it,
> so it's consistent to other tests, and it's easier to add more cleanups
> in _cleanup() function in the future if needed.
Done. I had based this test on generic/299 and generic/300, and a lot
of your comments are applicable to them as well. I can send a cleanup
patch to fix up those patches as well..
> > +_require_odirect
>
> _require_aio
Hmmm, generic/299 and generic/300 are missing _require_aio, while
doing async I/O. I'm a bit surprised this hasn't caused problems for
other file systems.
> > +
> > +_workout()
>
> There's no need to add the leading "_" to local function, it's reserved
> to common functions.
Done. (Actually, if we're not unmounting $SCRATCH, then we really
don't need a workout local function at all.)
> > + run_check $FIO_PROG $fio_config
>
> run_check is not recommanded and should be deprecated (maybe I should
> send a patch to document it in comment), as it hides failure in
> $seqres.full and exits if command returns non-zero.
>
> Just call $FIO_PROG command directly and check return value if
> necessary.
Thanks for suggesting dropping the run_check. I found a problem in
the fio receipe which was causing a FIO warning that I had been
missing.
BTW, all but one of the generic are still using run_check, and in the
one exception, generic/095, which uses --output=$seqres.full which is
causing us to lose all of the output of the earlier commands which
redirected their outputs to $seqres.full. So there's clearly a
"target rich environment" in terms of test clean up opportunities.
> > +if ! _scratch_unmount; then
> > + echo "failed to umount"
> > + status=1
> > + exit
> > +fi
>
> Is above _scratch_unmount check really needed? The test harness would
> umount $SCRATCH_DEV after test anyway.
Done.
Thanks for the review,
- Ted
next prev parent reply other threads:[~2021-03-07 23:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-10 20:58 [PATCH] generic: test which tries to exercise AIO/DIO into unwritten space Theodore Ts'o
2021-03-01 17:02 ` Theodore Ts'o
2021-03-01 17:14 ` Darrick J. Wong
2021-03-01 18:04 ` Theodore Ts'o
[not found] ` <CABnRu57hdKav3Mi8vQYeowZrQtFToMSzK23h4H2DuqGL0Dea2A@mail.gmail.com>
2021-03-02 3:33 ` Darrick J. Wong
2021-03-02 4:25 ` Su Yue
2021-03-03 20:02 ` Theodore Ts'o
2021-03-07 16:24 ` Eryu Guan
2021-03-07 23:11 ` Theodore Ts'o [this message]
2021-03-08 1:22 ` [PATCH -v2] " Theodore Ts'o
2021-03-15 21:10 ` Darrick J. Wong
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=YEVdqb9kcOV004ZO@mit.edu \
--to=tytso@mit.edu \
--cc=fstests@vger.kernel.org \
--cc=guan@eryu.me \
/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.