Re: [LTP] LTP test df01.sh detected different size of loop device in v5.19

From: Petr Vorel <pvorel@suse.cz>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>,
	linux-xfs@vger.kernel.org, Eric Sandeen <sandeen@sandeen.net>,
	Jan Kara <jack@suse.cz>, "Darrick J. Wong" <djwong@kernel.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-block@vger.kernel.org, Hannes Reinecke <hare@suse.de>,
	ltp@lists.linux.it
Subject: Re: [LTP] LTP test df01.sh detected different size of loop device in v5.19
Date: Fri, 19 Aug 2022 18:00:09 +0200	[thread overview]
Message-ID: <Yv+ziab2IiVIsqN6@pevik> (raw)
In-Reply-To: <974cc110-d47e-5fae-af5f-e2e610720e2d@redhat.com>

> 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


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp