[LTP] LTP test df01.sh detected different size of loop device in v5.19

[Petr Vorel]

> > -----Original Message-----
> > From: ltp <ltp-bounces+tim.bird=sony.com@lists.linux.it> On Behalf Of Petr Vorel

> > > On 8/18/22 12:01 PM, Petr Vorel wrote:
> > > >> 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).

> > > I think it would go after you remove the file, to ensure that no space usage
> > > changes are pending when you check.

> > > <tests>

> > > This seems to work fine (pseudopatch):

> > >         ROD_SILENT rm -rf mntpoint/testimg

> > > +       # Ensure free space change can be seen by statfs
> > > +       fsfreeze -f $TST_MNTPOINT
> > > +       fsfreeze -u $TST_MNTPOINT
> > It looks like it works. We might add small binary which just calls these 2
> > ioctl (FIFREEZE and FITHAW), just to be friendly to people on embedded
> > environment with minimal dependencies (yes, some people might not install
> > util-linux).

> Thank you!!  It's good to know that small embedded systems are still
> considered, and the consideration is much appreciated!  :-)

> Let me know if you'd like me to try writing the utility.
Thank you, Tim! I'll Cc you when sending this patch (likely next week).

You might also appreciate our effort to lower down loop device size (used for
all_filesystems): https://lore.kernel.org/ltp/Yv%2FkVXSK0xJGb3RO@pevik/

Kind regards,
Petr

>  -- Tim