fsck: disable par2's internal concurrency

It looks like par2 added its own concurrency a bit back, and when
that's combined with bup's fsck -j parallelism, a simple
t/test-fsck.sh run completely swamps a machine here, launching what
looks like 32 threads total (for a 4/8 core machine), and fully
saturating the CPU.

The current test, which specifies -j99 actually ends up launching 4
par2 invocations, each processing a single file, and then each par2
appears to assume it has the entire machine to itself and launches 8
threads (one per hardware "core").

The resulting test takes 100s, but if we disable par2's parallelism
with -t1, putting bup's -j argument back in control of the overall
level of concurrency, the run time comes down to 4s.

Signed-off-by: Rob Browning <rlb@defaultvalue.org>
Tested-by: Rob Browning <rlb@defaultvalue.org>

diff --git a/cmd/fsck-cmd.py b/cmd/fsck-cmd.py
index 35b45f8b514a0c07a36d6455bbedc6c85877425c..8fc4f7f303bccb16f8ffe55ee350db2cbd29d641 100755 (executable)
--- a/cmd/fsck-cmd.py
+++ b/cmd/fsck-cmd.py
@@ -52,14 +52,14 @@ def parv(lvl):
         return ['-qq']
 
 def par2_generate(base):
-    return run(['par2', 'create', '-n1', '-c200'] + parv(2)
+    return run(['par2', 'create', '-t1', '-n1', '-c200'] + parv(2)
                + ['--', base, base+'.pack', base+'.idx'])
 
 def par2_verify(base):
-    return run(['par2', 'verify'] + parv(3) + ['--', base])
+    return run(['par2', 'verify', '-t1'] + parv(3) + ['--', base])
 
 def par2_repair(base):
-    return run(['par2', 'repair'] + parv(2) + ['--', base])
+    return run(['par2', 'repair', '-t1'] + parv(2) + ['--', base])
 
 def quick_verify(base):
     f = open(base + '.pack', 'rb')