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 ... > > 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. --D > -Eric > > > ROD_SILENT rm -rf mntpoint/testimg > > > > # flush file system buffers, then we can get the actual sizes. > >
