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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: ltp <ltp-bounces+tim.bird=sony.com@xxxxxxxxxxxxxx> 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.
 -- Tim





[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux