I had a need to recompress some files the other day, while privately mirroring them to/from my reinstated cluster account. Despite hw.ncpus > 1 for many years now, we don't appear to have parallel versions of bzip2 and gzip installed. Whether or not bsdtar/libarchive support their use is another matter, though.
Given that this is a shared jail on a host with multiple other jails, we would probably want to lean towards not encouraging a ton of parallelization for compression unless absolutely necessary. Is your archival process something that would be able to handle using the builtin single-threaded tools for the time being? We are discussing migrating freefall to new hardware; however, are not quite there yet.
They were just one-offs, I'm not doing it that regularly, so no interruption to other users likely. Happy to close if EWONTFIX. Most specifically, I'm trying to fetch SONiC images from Azure CI for whitebox switches, which are ~1GB a pop, and this is problematic in the extreme to do over 4G LTE, where I am in semi-rural Scotland, because sporadic failures were happening with and without SOCKS5 and WireGuard in the mix, and Azure CI does not support HTTP range fetches (resumable downloads) So I'd cache them on the cluster, and they are most likely compressed already anyway (Arista aboot compatible .swi images just use the zip file format).
...or you could move on and use either zstd or xz which both do and performs in most cases if not all better?