Currently, enroot calls unsquashfs such that it will use all installed processors, which may not always be desirable. E.g., running a non-exclusive Slurm job restricts the number of usable processors, in our case 2 by default. I timed unsquashfs under these conditions, with and without explicitly setting the number of processors to use:

$ time unsquashfs -p 2 -user-xattrs -d /run/enroot-data/user-$UID/container /netscratch/enroot/nvcr.io_nvidia_pytorch_23.12-py3.sqsh
Parallel unsquashfs: Using 2 processors
...
real    0m37.332s
user    0m40.923s
sys     0m28.742s
$ rm -rf /run/enroot-data/user-$UID/container
$ time unsquashfs -user-xattrs -d /run/enroot-data/user-$UID/container /netscratch/enroot/nvcr.io_nvidia_pytorch_23.12-py3.sqsh
Parallel unsquashfs: Using 40 processors
...
real    0m41.553s
user    0m38.024s
sys     0m28.396s

On this older machine, setting an appropriate number of processors reduces the runtime by about 10%.

This pull request adds a new config variable, ENROOT_NUM_THREADS, which allows controlling the number of processors used by applies ENROOT_MAX_PROCESSORS to unsquashfs. It is unset by default, which maintains the current behavior.