> 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). > # flush file system buffers, then we can get the actual sizes. > sync > (although: what's the difference between $TST_MNTPOINT and mountpoint/ ?) Thanks for a report, fixed in 96ae882d3 ("df01.sh: Use $TST_MNTPOINT") > You just don't want to accidentally freeze the root filesystem ;) Sure :) Kind regards, Petr > -Eric
