Yes, but I’m asking you to use pbzip. bzip at best utilizes one core, both for packing and unpacking. pbzip uses as many cores as IO bandwith allows - with standard SATA SSDs that’s typically around 30.
pbzip can only utilize multiple cores if the archive was created with it as well.
I’ve searched for it and xz also doesn’t use multithreading by default, you can change the program tar uses to compress by passing the -I option. For xz using all possible CPU threads:
tar -cv -I 'xz -6 -T0' -f archive.tar.xz[list of directories]
The number indicates the compression ratio, the higher the number, the more compressed the archive will be but it will cost more in terms of memory and processing time
There’s nothing technically wrong with using xjf rather than xzf, but it’ll bite you if you ever use a non-linux platform as it’s a GNU extension. I’m not even sure busybox tar supports it.
I think the
-jalso compresses with bzip2 but I’m not sure if this is defined behavior or just a shortcutYes, but I’m asking you to use pbzip. bzip at best utilizes one core, both for packing and unpacking. pbzip uses as many cores as IO bandwith allows - with standard SATA SSDs that’s typically around 30.
pbzip can only utilize multiple cores if the archive was created with it as well.
Does something similar happen using
xz?I’ve searched for it and xz also doesn’t use multithreading by default, you can change the program tar uses to compress by passing the
-Ioption. For xz using all possible CPU threads:tar -cv -I 'xz -6 -T0' -f archive.tar.xz [list of directories]The number indicates the compression ratio, the higher the number, the more compressed the archive will be but it will cost more in terms of memory and processing time
Thanks for answering your own question, this is useful information.
There’s nothing technically wrong with using xjf rather than xzf, but it’ll bite you if you ever use a non-linux platform as it’s a GNU extension. I’m not even sure busybox tar supports it.