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 ... For a single 1MB file? inodegc is delayed 1 jiffie (max 10ms). If it's processed immediately because everything else is idle and nothing blocks, it will be done in 250-500 microsends. Of course, the moment you put such tests in a VM on a host that is running other VMs nothing is ever idle and inodegc delays are outside the control of the guest kernel/filesystem.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
