Re: xfs/566 execution time

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, May 21, 2025 at 09:37:53AM +0000, Shinichiro Kawasaki wrote:
> On May 20, 2025 / 20:19, Darrick J. Wong wrote:
> > On Tue, May 20, 2025 at 07:08:58AM -0700, Christoph Hellwig wrote:
> > > Hi Darrick,
> > > 
> > > we regularly see execution times of more than half a day for xfs/566
> > > on a 30ish TB SMR HDD.  Do you think there might be a useful way to
> > > scale down the load on rotational devices?
> > 
> > Hrmm.  Is that the only one that does that, or do the other scrub tests
> > take a while too?
> 
> As to the test with SMR HDDs, I observed very long test run on two test cases:
> xfs/566 and xfs/732.
> 
> > If it's just that one, and setting SOAK_DURATION=2m
> > results in the test cutting off after 2min, then I'll craft some sort of
> > fix to constrain the runtime.
> 
> I added,
> 
>  "export SOAK_DURATION=2m"
> 
> to local.config and ran xfs/566, but that setting does not look working.
> The test case rusn more than a half an hour...

Huh, that's /very/ strange.  In the absence of a SOAK_DURATION, the test
should only run itself for 30 seconds.  From common/fuzzy,
_scratch_xfs_stress_scrub does this to set the end-time:

	if [ -n "$SOAK_DURATION" ]; then
		end="$((start + SOAK_DURATION))"
	else
		end="$((start + (30 * TIME_FACTOR) ))"
	fi

and then __stress_scrub_fsx_loop does:

	while __stress_scrub_running "$end" "$runningfile"; do
		# Need to recheck running conditions if we cleared anything
		__stress_scrub_clean_scratch && continue
		duration=$(___stress_scrub_duration "$end" "$remount_period")
		___scrub_run_fsx $duration $d_args &

which should be sufficient to exit the fsx loop.  Then we go back to
_scratch_xfs_stress_scrub and:

	# Wait until the designated end time or fsstress dies, then kill all of
	# our background processes.
	while __stress_scrub_running "$end" "$runningfile"; do
		sleep 1
	done
	_scratch_xfs_stress_scrub_cleanup

which just waits for fsx and scrub to exit.  If you start this test and
wait about 45 seconds or so, can you send me the ps output so I can try
to figure out which component(s) aren't stopping in time?

--D