Re: time impact of the delta signature

Hello Denis

> [...]
> the delta signature algorithm is implemented in librsync library that
> libdar relies on throught its API. Thus there is little thing I can do
> about it from libdar... and splitting the files per block on which to
> calculate the delta signatures will make the thing very complicated in
> dar archive format as you will have to detect block boundary (adding
> marks in the data flow for example), protect them against corruption,
> remove these marks from the data, stick block of file data toghether
> in order to restore a given file...
> [...]

In reality I'm not asking to change dar's internal architecture, but only the parameter of the delta checksum mechanism, when calling librsync.
I made a quick study of the problem and my hypotesis revealed to be correct. I propose you a solution to improve the signature speed dramatically (the execution time of the signature is minimal instead of the huge overhead encountered). Let me say that I use the delta diff only if the files are bigger than, say 100 MB. The granularity of the difference (i.e. the minimal chunk to be written in delta file) for my application is, let me say, 4 MB (whereas default value is 2048 bytes).

In practice, for me it is sufficient to patch the file [...]/src/libdar/generic_rsync.cpp
with the following difference:
---
 #ifdef RS_DEFAULT_STRONG_LEN
 	    job = rs_sig_begin(RS_DEFAULT_BLOCK_LEN, RS_DEFAULT_STRONG_LEN);
 #else
 		// should use RS_BLAKE2_SIG_MAGIC in place of RS_MD4_SIG_MAGIC
 		// but not compatible with librsync < 1.0
-	    job = rs_sig_begin(RS_DEFAULT_BLOCK_LEN, 0, RS_MD4_SIG_MAGIC);
+	    job = rs_sig_begin(1024*1024*4, 0, RS_MD4_SIG_MAGIC);
 #endif
---
i.e. by substituting the RS_DEFAULT_BLOCK_LEN with my own datum 1024*1024*4.

I tested and signature, delta diff and extraction of incremental delta diff works properly (and really fast).

Surely the BLOCK_LEN could be dynamically adjusted to the file size. But for now this value simply works well.

Regards
Andy