As I understand it, the -b# option is the input option. Read -b# amount of KB then compress/decompress with algorithm.
Some filesystem block sizes can influence the total compression. If a file system writes in 8K blocks, and you have a 32K compression block size, the max compression you can get is 4:1. So either a percentage of compressibility threshold (only report compression if at least x% compressible) or an output block size alignment option could take care of this.
In other words... if using 50% percentage of compressibility and a 16K block size, Ignore any results that do not get at least 8k of reduction. Consider those as a 1:1.
...or....
if using an output block alignment size of 8K and a 16K block size, the same as above would happen. If the algorithm can not reduce 16k to at least 8K, then no reduction for that chunk will be logged.
As I understand it, the -b# option is the input option. Read -b# amount of KB then compress/decompress with algorithm.
Some filesystem block sizes can influence the total compression. If a file system writes in 8K blocks, and you have a 32K compression block size, the max compression you can get is 4:1. So either a percentage of compressibility threshold (only report compression if at least x% compressible) or an output block size alignment option could take care of this.
In other words... if using 50% percentage of compressibility and a 16K block size, Ignore any results that do not get at least 8k of reduction. Consider those as a 1:1. ...or.... if using an output block alignment size of 8K and a 16K block size, the same as above would happen. If the algorithm can not reduce 16k to at least 8K, then no reduction for that chunk will be logged.