On Fri, Dec 06, 2024 at 04:09:17PM -0800, Darrick J. Wong wrote: > On Fri, Nov 29, 2024 at 12:22:16PM +0800, Zorro Lang wrote: > > On Wed, Nov 27, 2024 at 03:51:30PM +1100, Dave Chinner wrote: > > > Hi folks, > > > > > > This patchset introduces the ability to run fstests concurrently > > > instead of serially as the current check script does. A git branch > > > containing this patchset can be pulled from here: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/dgc/xfstests-dev.git check-parallel > > > > Hi Dave, > > > > I've merged your "check-parallel" branch, and rebase on fstests' > > patches-in-queue branch (which is nearly the next release). I just > > pushed a new branch "for-dave-check-parallel" which fixed all > > conflicts. It'll be "next next" release, feel free to update base > > on that. I'll test that branch too :) > > I ran this through my test infrastructure at zorro's request. I saw a > bunch of loop dev errors trickle out: > > --- xfs/129.out > +++ xfs/129.out.bad > @@ -2,3 +2,6 @@ > Create the original file blocks > Reflink every other block > Create metadump file, restore it and check restored fs > +losetup: /dev/loop0: detach failed: No such device or address > +Cannot destroy loop device /dev/loop0 > +(see /var/tmp/fstests/xfs/129.full for details) Almost certainly I missed the conversion of names in _xfs_verify_metadump_v1() from "data_loop" to "md_data_loop_dev" and such. common/metadump is liley missing "unset md_data_loop_dev" after destroying the loop devices, too. Not sure why that isn't triggering on my setup, trivial to fix. I'll sort it out and fold it back into the original loopdev cleanup patch in the set. > and I noticed the runtimes for running serially went way up. Not seeing that here; I don't think any of the changes I've made should affect the runtime of a normal check test pass; the tests should take the same time to run or run faster after this patchset, even serially... > Not sure > if that was because my dev tree has a bunch of metadir fixes in it or > not; will run that again over the weekend with upstream tot to see if it > that brings the total runtime back down. OK. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
