On Fri, Nov 29, 2024 at 09:10:09AM -0800, Darrick J. Wong wrote: > On Wed, Nov 27, 2024 at 03:51:46PM +1100, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > When running lots of tests in parallel, there are lots of > > filesystems and block devices changing state. This generates a lot > > of udev events when means the udev event queue is rarely empty. > > Unfortunately, an empty event queue is what udev settling waits > > upon. Hence calling UDEV_SETTLE_PROG can mean waiting for a lot of > > time for other tests to stop generating udev events. > > > > For the majority of cases, what we care about is that udev has > > performed device node addition or removal, not that there are no > > udev events pending. Recent(-ish) systemd releases support 'udevadm > > wait' to wait for a specific file to be created or unlinked rather > > than waiting for the event that does that work to be completed. > > > > Hence we don't have to wait for the udev event queue to empty, > > just for the udev event that does the device node manipulation to > > complete. > > > > Introduce detection of 'udevadm wait' support and a _udev_wait() > > wrapper function to use it if it is available. If it isn't, the use > > the existing UDEV_SETTLE_PROG behaviour. > > > > Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> > > --- > > common/config | 35 +++++++++++++++++++++++++---------- > > common/rc | 25 ++++++++++++++++--------- > > tests/btrfs/291 | 5 +++-- > > tests/generic/081 | 6 +++--- > > tests/generic/108 | 7 +++---- > > tests/generic/459 | 6 +++--- > > 6 files changed, 53 insertions(+), 31 deletions(-) > > > > diff --git a/common/config b/common/config > > index fcff0660b..41b8f29d1 100644 > > --- a/common/config > > +++ b/common/config > > @@ -165,7 +165,7 @@ export XFS_MDRESTORE_PROG="$(type -P xfs_mdrestore)" > > export XFS_ADMIN_PROG="$(type -P xfs_admin)" > > export XFS_GROWFS_PROG=$(type -P xfs_growfs) > > export XFS_SPACEMAN_PROG="$(type -P xfs_spaceman)" > > -export XFS_SCRUB_PROG="$(type -P xfs_scrub)" > > +#export XFS_SCRUB_PROG="$(type -P xfs_scrub)" > > If you have problems with online fsck, please report them to the mailing > list. Thank you for finding this, Darrick, but there is absolutely no need to treat me like a n00b who doesn't know how kernel development works. I simply forgot I did this when debugging the hundreds of busy-after-unmount failures that were occurring whilst trying to get this patchset to work. I turned off scrub while I debugged these issues to reduce the amount of noise and variations in the end-of-test failures, and I simply never noticed that I had left this hunk in the patch. So, nothing wrong with scrub, just a simple case of missing one line of debug changes in a patchset that touches 400+ files.... Removed. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
