From: Petr Vorel <pvorel@suse.cz>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Dave Chinner <david@fromorbit.com>,
linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Jan Kara <jack@suse.cz>, Hannes Reinecke <hare@suse.de>,
linux-xfs@vger.kernel.org, ltp@lists.linux.it
Subject: Re: LTP test df01.sh detected different size of loop device in v5.19
Date: Thu, 18 Aug 2022 19:01:05 +0200 [thread overview]
Message-ID: <Yv5wUcLpIR0hwbmI@pevik> (raw)
In-Reply-To: <Yv5oaxsX6z2qxxF3@magnolia>
> On Thu, Aug 18, 2022 at 11:05:33AM -0500, Eric Sandeen wrote:
> > On 8/18/22 10:25 AM, Petr Vorel wrote:
> > > Hi Eric, all,
> > ...
> > >> IOWS, I think the test expects that free space is reflected in statfs numbers
> > >> immediately after a file is removed, and that's no longer the case here. They
> > >> change in between the df check and the statfs check.
> > >> (The test isn't just checking that the values are correct, it is checking that
> > >> the values are /immediately/ correct.)
> > >> Putting a "sleep 1" after the "rm -f" in the test seems to fix it; IIRC
> > >> the max time to wait for inodegc is 1s. This does slow the test down a bit.
> > > Sure, it looks like we can sleep just 50ms on my hw (although better might be to
> > > poll for the result [1]), I just wanted to make sure there is no bug/regression
> > > before hiding it with sleep.
> > > Thanks for your input!
> > > Kind regards,
> > > Petr
> > > [1] https://people.kernel.org/metan/why-sleep-is-almost-never-acceptable-in-tests
> > >> -Eric
> > > +++ testcases/commands/df/df01.sh
> > > @@ -63,6 +63,10 @@ df_test()
> > > tst_res TFAIL "'$cmd' failed."
> > > fi
> > > + if [ "$DF_FS_TYPE" = xfs ]; then
> > > + tst_sleep 50ms
> > > + fi
> > > +
> > Probably worth at least a comment as to why ...
Sure, that was just to document possible fix. BTW even 200ms was not reliable in
the long run => not a good solution.
> > Dave / Darrick / Brian - I'm not sure how long it might take to finish inodegc?
> > A too-short sleep will let the flakiness remain ...
> A fsfreeze -f / fsfreeze -u cycle will force all the background garbage
> collection to run to completion when precise free space accounting is
> being tested.
Thanks for a hint, do you mean to put it into df_test after creating file with
dd to wrap second df_verify (calls df) and df_check (runs stat and compare values)?
Because that does not help - it fails when running in the loop (managed to break after 5th run).
Kind regards,
Petr
df_test()
{
local cmd="$1 -P"
df_verify $cmd
if [ $? -ne 0 ]; then
return
fi
df_check $cmd
if [ $? -ne 0 ]; then
tst_res TFAIL "'$cmd' failed, not expected."
return
fi
ROD_SILENT dd if=/dev/zero of=mntpoint/testimg bs=1024 count=1024
if [ "$DF_FS_TYPE" = xfs ]; then
fsfreeze -f $TST_MNTPOINT
fi
df_verify $cmd
df_check $cmd
if [ $? -eq 0 ]; then
tst_res TPASS "'$cmd' passed."
else
tst_res TFAIL "'$cmd' failed."
fi
if [ "$DF_FS_TYPE" = xfs ]; then
fsfreeze -u $TST_MNTPOINT
fi
ROD_SILENT rm -rf mntpoint/testimg
# flush file system buffers, then we can get the actual sizes.
sync
}
df_verify()
{
$@ >output 2>&1
if [ $? -ne 0 ]; then
grep -q -E "unrecognized option | invalid option" output
if [ $? -eq 0 ]; then
tst_res TCONF "'$@' not supported."
return 32
else
tst_res TFAIL "'$@' failed."
cat output
return 1
fi
fi
}
df_check()
{
if [ "$(echo $@)" = "df -i -P" ]; then
local total=$(stat -f mntpoint --printf=%c)
local free=$(stat -f mntpoint --printf=%d)
local used=$((total-free))
else
local total=$(stat -f mntpoint --printf=%b)
local free=$(stat -f mntpoint --printf=%f)
local used=$((total-free))
local bsize=$(stat -f mntpoint --printf=%s)
total=$((($total * $bsize + 512)/ 1024))
used=$((($used * $bsize + 512) / 1024))
fi
grep ${TST_DEVICE} output | grep -q "${total}.*${used}"
if [ $? -ne 0 ]; then
echo "total: ${total}, used: ${used}"
echo "df saved output:"
cat output
echo "df output:"
$@
return 1
fi
}
> --D
> > -Eric
> > > ROD_SILENT rm -rf mntpoint/testimg
> > > # flush file system buffers, then we can get the actual sizes.
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-xfs@vger.kernel.org, Jan Kara <jack@suse.cz>,
Eric Sandeen <sandeen@sandeen.net>,
Dave Chinner <david@fromorbit.com>,
linux-block@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
ltp@lists.linux.it
Subject: Re: [LTP] LTP test df01.sh detected different size of loop device in v5.19
Date: Thu, 18 Aug 2022 19:01:05 +0200 [thread overview]
Message-ID: <Yv5wUcLpIR0hwbmI@pevik> (raw)
In-Reply-To: <Yv5oaxsX6z2qxxF3@magnolia>
> On Thu, Aug 18, 2022 at 11:05:33AM -0500, Eric Sandeen wrote:
> > On 8/18/22 10:25 AM, Petr Vorel wrote:
> > > Hi Eric, all,
> > ...
> > >> IOWS, I think the test expects that free space is reflected in statfs numbers
> > >> immediately after a file is removed, and that's no longer the case here. They
> > >> change in between the df check and the statfs check.
> > >> (The test isn't just checking that the values are correct, it is checking that
> > >> the values are /immediately/ correct.)
> > >> Putting a "sleep 1" after the "rm -f" in the test seems to fix it; IIRC
> > >> the max time to wait for inodegc is 1s. This does slow the test down a bit.
> > > Sure, it looks like we can sleep just 50ms on my hw (although better might be to
> > > poll for the result [1]), I just wanted to make sure there is no bug/regression
> > > before hiding it with sleep.
> > > Thanks for your input!
> > > Kind regards,
> > > Petr
> > > [1] https://people.kernel.org/metan/why-sleep-is-almost-never-acceptable-in-tests
> > >> -Eric
> > > +++ testcases/commands/df/df01.sh
> > > @@ -63,6 +63,10 @@ df_test()
> > > tst_res TFAIL "'$cmd' failed."
> > > fi
> > > + if [ "$DF_FS_TYPE" = xfs ]; then
> > > + tst_sleep 50ms
> > > + fi
> > > +
> > Probably worth at least a comment as to why ...
Sure, that was just to document possible fix. BTW even 200ms was not reliable in
the long run => not a good solution.
> > Dave / Darrick / Brian - I'm not sure how long it might take to finish inodegc?
> > A too-short sleep will let the flakiness remain ...
> A fsfreeze -f / fsfreeze -u cycle will force all the background garbage
> collection to run to completion when precise free space accounting is
> being tested.
Thanks for a hint, do you mean to put it into df_test after creating file with
dd to wrap second df_verify (calls df) and df_check (runs stat and compare values)?
Because that does not help - it fails when running in the loop (managed to break after 5th run).
Kind regards,
Petr
df_test()
{
local cmd="$1 -P"
df_verify $cmd
if [ $? -ne 0 ]; then
return
fi
df_check $cmd
if [ $? -ne 0 ]; then
tst_res TFAIL "'$cmd' failed, not expected."
return
fi
ROD_SILENT dd if=/dev/zero of=mntpoint/testimg bs=1024 count=1024
if [ "$DF_FS_TYPE" = xfs ]; then
fsfreeze -f $TST_MNTPOINT
fi
df_verify $cmd
df_check $cmd
if [ $? -eq 0 ]; then
tst_res TPASS "'$cmd' passed."
else
tst_res TFAIL "'$cmd' failed."
fi
if [ "$DF_FS_TYPE" = xfs ]; then
fsfreeze -u $TST_MNTPOINT
fi
ROD_SILENT rm -rf mntpoint/testimg
# flush file system buffers, then we can get the actual sizes.
sync
}
df_verify()
{
$@ >output 2>&1
if [ $? -ne 0 ]; then
grep -q -E "unrecognized option | invalid option" output
if [ $? -eq 0 ]; then
tst_res TCONF "'$@' not supported."
return 32
else
tst_res TFAIL "'$@' failed."
cat output
return 1
fi
fi
}
df_check()
{
if [ "$(echo $@)" = "df -i -P" ]; then
local total=$(stat -f mntpoint --printf=%c)
local free=$(stat -f mntpoint --printf=%d)
local used=$((total-free))
else
local total=$(stat -f mntpoint --printf=%b)
local free=$(stat -f mntpoint --printf=%f)
local used=$((total-free))
local bsize=$(stat -f mntpoint --printf=%s)
total=$((($total * $bsize + 512)/ 1024))
used=$((($used * $bsize + 512) / 1024))
fi
grep ${TST_DEVICE} output | grep -q "${total}.*${used}"
if [ $? -ne 0 ]; then
echo "total: ${total}, used: ${used}"
echo "df saved output:"
cat output
echo "df output:"
$@
return 1
fi
}
> --D
> > -Eric
> > > ROD_SILENT rm -rf mntpoint/testimg
> > > # flush file system buffers, then we can get the actual sizes.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-08-18 17:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-12 13:20 LTP test df01.sh detected different size of loop device in v5.19 Petr Vorel
2022-08-12 13:24 ` Petr Vorel
2022-08-12 14:00 ` Petr Vorel
2022-08-12 14:00 ` [LTP] " Petr Vorel
2022-08-14 22:44 ` Dave Chinner
2022-08-14 22:44 ` [LTP] " Dave Chinner
2022-08-15 9:31 ` Petr Vorel
2022-08-15 9:31 ` [LTP] " Petr Vorel
2022-08-15 20:09 ` Eric Sandeen
2022-08-15 20:09 ` [LTP] " Eric Sandeen
2022-08-18 15:25 ` Petr Vorel
2022-08-18 15:25 ` [LTP] " Petr Vorel
2022-08-18 16:05 ` Eric Sandeen
2022-08-18 16:05 ` [LTP] " Eric Sandeen
2022-08-18 16:27 ` Darrick J. Wong
2022-08-18 16:27 ` [LTP] " Darrick J. Wong
2022-08-18 17:01 ` Petr Vorel [this message]
2022-08-18 17:01 ` Petr Vorel
2022-08-18 21:19 ` Eric Sandeen
2022-08-18 21:19 ` [LTP] " Eric Sandeen
2022-08-19 16:00 ` Petr Vorel
2022-08-19 16:00 ` [LTP] " Petr Vorel
2022-08-19 16:06 ` Bird, Tim
2022-08-19 16:06 ` Bird, Tim
2022-08-19 19:30 ` Petr Vorel
2022-08-19 19:30 ` Petr Vorel
2022-08-18 21:02 ` Dave Chinner
2022-08-18 21:02 ` [LTP] " Dave Chinner
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=Yv5wUcLpIR0hwbmI@pevik \
--to=pvorel@suse.cz \
--cc=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=djwong@kernel.org \
--cc=hare@suse.de \
--cc=jack@suse.cz \
--cc=linux-block@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=sandeen@sandeen.net \
/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.