> -----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
