On 8/18/22 12:01 PM, Petr Vorel wrote:

quoted

On Thu, Aug 18, 2022 at 11:05:33AM -0500, Eric Sandeen wrote:

quoted

On 8/18/22 10:25 AM, Petr Vorel wrote:

quoted

Hi Eric, all,

quoted

quoted

...

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

(The test isn't just checking that the values are correct, it is checking that
the values are /immediately/ correct.)

quoted

quoted

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

quoted

Thanks for your input!

quoted

quoted

quoted

Kind regards,
Petr

quoted

quoted

quoted

[1] https://people.kernel.org/metan/why-sleep-is-almost-never-acceptable-in-tests

quoted

quoted

quoted

quoted

-Eric

quoted

quoted

quoted

+++ testcases/commands/df/df01.sh

@@ -63,6 +63,10 @@ df_test()
 		tst_res TFAIL "'$cmd' failed."
 	fi

quoted

quoted

quoted

+	if [ "$DF_FS_TYPE" = xfs ]; then
+		tst_sleep 50ms
+	fi
+

quoted

quoted

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.

quoted

quoted

Dave / Darrick / Brian - I'm not sure how long it might take to finish inodegc?
A too-short sleep will let the flakiness remain ...

quoted

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