From: Wang Yugui <wangyugui@e16-tech.com>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/297: fix the delta time based on stat
Date: Fri, 10 Jun 2022 14:00:35 +0800 [thread overview]
Message-ID: <20220610140034.949C.409509F4@e16-tech.com> (raw)
In-Reply-To: <20220610051926.75oiyafys56dfdy3@zlang-mailbox>
Hi,
> On Fri, Jun 10, 2022 at 12:36:24PM +0800, Wang Yugui wrote:
> > Hi,
> >
> > > On Fri, Jun 10, 2022 at 10:35:53AM +0800, Wang Yugui wrote:
> > > > stat -c '%Y' report seconds as int, so the delta 2.01s may result as 3s.
> > > >
> > > > Signed-off-by: Wang Yugui <wangyugui@e16-tech.com>
> > > > ---
> > > > tests/generic/297 | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/tests/generic/297 b/tests/generic/297
> > > > index 6bdc3e1c..e3082202 100755
> > > > --- a/tests/generic/297
> > > > +++ b/tests/generic/297
> > > > @@ -51,7 +51,7 @@ for i in $(seq 0 $fnr); do
> > > > touch $TEST_DIR/after
> > > > before=$(stat -c '%Y' $TEST_DIR/before)
> > > > after=$(stat -c '%Y' $TEST_DIR/after)
> > > > - delta=$((after - before))
> > > > + delta=$((after - before -1)) # 2.01s may result as 3s; so -1
> > >
> > > What issue is this change trying to fix? "timeout=8"s is not long enough?
> >
> > for the command
> > $TIMEOUT_PROG -s INT ${kill_after}s
> >
> > delta=$((after - before )) may report 'kill_after+1' in some case.
> >
> > so no relationship to "timeout=8" or "timeout=2".
> >
> > '$XFS_IO_PROG -f -c reflink' without '$TIMEOUT_PROG -s INT ${kill_after}s'
> > may take 20s because this is a very complex reflink.
>
> Hmm... still don't understand what are you trying to fix.
>
> That reflink operation need long time, that's expected. The first time it's
> running in a while loop for getting a proper testing size, no matter 8.01s
> or 9s, I think it's all good.
>
> The second time the reflink run with `TIMEOUT_PROG 2s`, we expect it can be
> killed in 'timeout=8s', that's long enough. I think it's not necessary to
> care about it's keep running in 8.01s or 9s.
drop this patch please.
btrfs of generic/297 has a few freqency to fail.
maybe because $XFS_IO_PROG is interrupt by timeout,
but the reflink inside kernel continue to finish.
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2022/06/10
prev parent reply other threads:[~2022-06-10 6:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 2:35 [PATCH] generic/297: fix the delta time based on stat Wang Yugui
2022-06-10 4:24 ` Zorro Lang
2022-06-10 4:36 ` Wang Yugui
2022-06-10 5:03 ` Dave Chinner
2022-06-10 5:12 ` Wang Yugui
2022-06-10 5:19 ` Zorro Lang
2022-06-10 6:00 ` Wang Yugui [this message]
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=20220610140034.949C.409509F4@e16-tech.com \
--to=wangyugui@e16-tech.com \
--cc=fstests@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.