Re: debug parallel root checks

[Ruediger Meier <sweet_f_a@gmx.de>]

On Friday 09 March 2018, Karel Zak wrote:
> On Fri, Mar 09, 2018 at 04:06:08PM +0100, Ruediger Meier wrote:
> > On Friday 09 March 2018, Ruediger Meier wrote:
> > > Hi,
> > >
> > > Our parallel root checks look already nice on the first view.
> > > On the second view they fail the stress test, at least on my
> > > system.
> >
> > Just an arbitrary example. Sometimes I get this failure
> >
> > $ cat  tests/diff/mount/uuid
> > --- /tmp/ul2/tests/expected/mount/uuid  2018-03-09
> > 11:04:54.992654305 +0100 +++ /tmp/ul2/tests/output/mount/uuid   
> > 2018-03-09 15:55:00.168028810 +0100 @@ -1 +1,2 @@
> > -Success
> > +mount: /tmp/ul2/tests/output/mount/uuid-mnt: can't find
> > UUID="f102445a-f6f3-4657-bc58-81ff164fc0d9". +A) Cannot find
> > /dev/loop10 in /proc/mounts
> >
> >
> > So mount can't find that UUID although it was found before by
> > ts_uuid_by_devname, i.e. by blkid(1).
> >
> > What could be the problem:
> >    - another test thread removed the UUID
> >    - invalid blkid cache
> >    - a bug?
>
> And note that I do not use --parallel as test case before a release.
> It seems still too fragile to provide serious functional tests.

Of course, but it helped already somehow to understand our test-suite 
better and discovered some bugs which could also happen 
without --parallel.

I'm still sceptical about our multiple locks strategy (deadlocks!?). 
Also the speed improvement is not significant against just running two 
separate "xargs threads", one for root and one for non-root. Anyways 
it's interesting to play around with the locks and maybe we could even 
avoid the big scsi_debug lock one day by re-using the module instead of
modprobe/rmmod.

cu,
Rudi