Re: [ANNOUNCE] fstests: for-next branch updated to v2025.02.23

[David Sterba <dsterba@suse.cz>]

On Thu, Feb 27, 2025 at 09:52:21AM -0800, Darrick J. Wong wrote:
> >     ...
> >     (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/140.out
> > /home/fdmanana/git/hub/xfstests/results//btrfs/140.out.bad'  to see
> > the entire diff)
> > btrfs/141 1s ... [failed, exit status 1]- output mismatch (see
> > /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad)
> >     --- tests/btrfs/141.out 2024-06-04 12:18:50.084308982 +0100
> >     +++ /home/fdmanana/git/hub/xfstests/results//btrfs/141.out.bad
> 
> ...which I never saw because I don't have SCRATCH_DEV_POOL set up. :(
> 
> I traced it to this code:
> 
> 	while [[ -z $( (( BASHPID % nr_mirrors == mirror )) &&
> 		exec $XFS_IO_PROG \
> 			-c "pread -b $size $offset $size" $file) ]]; do
> 		:
> 	done
> 
> If memory serves, btrfs' raid rotoring is based on the global pid
> number, right?  If so, then this is broken with the new run_privatens
> isolation (i.e. the commit you referenced) because the pids that the
> test program sees are private to that namespace.
> 
> IOWS, the subprocesses created in the loop test might appear to have
> pids 3 -> 4 -> 5, but those could very well be 100, 200, 300 in the
> global namespace, in which case all reads go to the same mirror
> (assuming nr_mirrors==2 as it does in btrfs/140).
> 
> A really shitty hack around that is this:
> 
> 	for ((i = 0; i < (nr_mirrors * 4); i++)); do
> 		$XFS_IO_PROG -c "pread -b $size $offset $size" $file
> 	done >> $seqres.full
> 
> but now we're just hoping that reading 8x actually manages to hit both
> mirrors at some point in this test.  But that doesn't work reliably in
> btrfs/141 even if I turn it up from 4 to 11.
> 
> Is there *any* other way to trigger read from a specific mirror?

Yes, but it's still in the experimental build. There's another
algorithm to pick the mirror based on the load so we're departing from
the pid based selection in the long run.

We can skip the tests that depend on the pids which seem to be even more
unpredictable with the namespaces. This will reduce the test coverage in
non-developer builds but the test is not something critical I guess.