20

Rsync has command line arguments for compression:

-z, --compress              compress file data during the transfer
    --compress-level=NUM    explicitly set compression level

What does --compress-level mean? Which numbers can be used as level?

4 Answers 4

21

It's values between 0-9. Where 1 is fastest and 9 is the most compressed. Other than that there's correlation between rsync and zlib where rsync tells the zlib library to "use the default compression". In zlib's docs, it says this:

Z_DEFAULT_COMPRESSION requests a default compromise between speed and compression (currently equivalent to level 6).

2
  • So, the origin of these levels is zlib?
    – cronfy
    Nov 18, 2016 at 8:52
  • yes, but you will be able if you set value for example in rsync 0 then it would uncompressed and then send in that form.
    – Michal
    Nov 18, 2016 at 8:53
5

rsync since version 3.2.0 supports more than zlib:

--compress, -z
       turn on compression
--compress-choice=STR, --zc=STR
       choose compression from lz4 (fastest), zstd, zlibx, zlib (slowest), none
--compress-level=NUM, --lz=NUM
       zlib and zstd can be tuned with compression level
       zlib from 1 (lowest) to 9 (highest), default 6
       zstd from -131072 to 22, default 3
4

Note that the local rsync documentation covers the information about --compress-level.

To find it:

  1. run man rsync
  2. type /compress-level (note the slash) and press ENTER
  3. type / and ENTER (repeat until satisfied)
  4. gotcha!
       --compress-level=NUM
              Explicitly set the compression level to use (see --compress) in‐
              stead of letting it default.  Allowed values for NUM are between
              0 and 9; default when --compress option is specified is  6.   If
              NUM is non-zero, the --compress option is implied.

Having said that, I admit it's not very explanatory about the actual behavior of NUM... but bigger NUM means more compression. So:

rsync --compress-level=9

That enables maximum compression (so, maximum CPU usage).

Note: very high compression levels are useful for very limited connection bandwidth. On high-speed networks, this compression just slow down everything, since your CPU is busy in compressing instead of just copying.

3

The environment used was composed by two docker containers used with MACVLAN + some noise traffic (which gives around ±1% error) The fileX - in my case - is a binary one

So, below are the result of rsync tarred files versus rsync with compression (option -z) untarred files

      1. File tarred + rsync without compression (rsync -axvPAH fileX.tar destination:/path)

    File size is 56933 bits (fileX.tar)
    Transfer difference is 4735665-4673346=62319 bits

      2. File tarred + rsync with default compression (rsync -axvPAH -z fileX destination:/path)

    File size is 56933 (fileX.tar)
    Transfer difference is 4933845-4871608=62237

      3. File tarred + rsync with maximum compression (rsync -axvPAH -z --compress-level=9 fileX.tar destination:/path)

    File size is 56933 bits (fileX.tar)
    Transfer difference is 4870664-4808387=62277

      4. File untarred + rsync with default compression (rsync -axvPAH -z fileX destination:/path)

    File size is 237525 bits (fileX)
    Transfer difference is 4669946-4607637=62309 bits

      5. File untarred + rsync with maximum compression (rsync -axvPAH -z --compress-level=9 fileX destination:/path)

    File size is 237525 bits (fileX)
    Transfer difference is 4806735-4744764=61971 bits

      6. File untarred + rsync without compression (makes no sense since it’s the most bandwidth consuming one) 
1
  • 1
    Useful data. Would be even better if it included total time (tarring plus rsync) so an analysis on time could also be done, since almost all options you listed are about the same bandwith expenditure
    – WurmD
    Apr 28, 2020 at 9:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .