• aard@kyu.de
    link
    fedilink
    arrow-up
    17
    ·
    1 year ago

    You also don’t need the dash for the short options.

    Also, if you’re compressing with bzip2 and have archives bigger than a few megabytes I’ll like you a lot more if you do it with --use-compress-prog=pbzip2

    • sebastiancarlos@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      23
      arrow-down
      1
      ·
      edit-2
      1 year ago

      You also don’t need the dash for the short options.

      True, but I refuse to entertain such a non-standard option format. It’s already enough to tolerate find’s.

      • aard@kyu.de
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        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.

          • Programmer Belch@lemmy.dbzer0.com
            link
            fedilink
            English
            arrow-up
            3
            ·
            1 year ago

            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

      • tony@lemmy.hoyle.me.uk
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        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.