Re: time impact of the delta signature

Hello Denis, thanks for the detailed explanations.

Due to the heterogeneity of usages also I'm planning to use different signature block length.
The possibility to have a user-selectable block size is surely a good option: if I archive virtual machine virtual disks images (this is my need at the moment) I can use a large signature block, but when I will have the need to archive small files, even the default 2048 B block length may be suboptimal (i.e. too large).

As you pointed previously you are considering enriching the option:
"--delta sig:N"
where N is the size of the delta signature, with the further option that, if N is small, a "variable blocksize" feature activates.
May I give you the following suggestion?

I would like to see the following option (in compact form):

"--delta sig:N[:F]"

N can be any positive integer representing the signature block length. If N has a small value (1, 2 or maybe even 3), then the variable size activates.
In this case the optional parameter F (real number, default 1.0) may be present.

In those circumstances, mathematically, if the filesystem size is S, the block-len size will be computed by dar as:

block-len size = F * S^(1/N)
(with a minimum value, say 256 B - that I see also in the librsync proposal for variable blocksize).

If I use N=1, then the blocksize will be simply proportional to the filesize ( S^(1/1)=S ). 
Example:
"--delta sig:1:0.0001"
it means that the blocksize will be 0.0001 times the filesize.

If N=2 the blocksize will be proportional to the square root of the filesize ( S^(1/2)=sqrt(S) ).
Example:
"--delta sig:2" or "--delta sig:2:1"
it means that the blocksize will be the square root of the filesize (suggested value).

Example:
"--delta sig:2:4"
it means that the blocksize will be four times the square root of the filesize (faster execution, but larger delta diffs).

If it is considered useful also the cube root, then it could be activated an option N=3.

For larger N values, N simply represents the constant blocksize (that you already implemented in dar-2.6.3.RC1).

It is just a little suggestion. I think that this kind of option could give sufficient flexibility on the variety of usages.


> > I'm using a librsync version 1.0 (default package as found in
> > opensuse 15.0), maybe latest versions are more efficient. Will try
> > build 2.0.2.
> 
> Yep, this is something I have to test too...


Tested, but from a performance point of view, I didn't notice any improvement.

Thanks,
Andy.