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 # flush file system buffers, then we can get the actual sizes. sync (although: what's the difference between $TST_MNTPOINT and mountpoint/ ?) You just don't want to accidentally freeze the root filesystem ;) -Eric
