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 -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
