Re: Discussion about file format for the future

[Robert Nichols]

On 6/9/20 9:44 AM, rhkramer@gmail.com wrote:
> In the case of rdiff-back, it wouldn't surprise me that diffs (deltas) are
> stored as forward deltas, and, in removing old deltas, a new "base" must be
> created before deleting the deltas.  (My words probably aren't exactly
> correct, I hope they are correct enough to explain my point.)

That's not how rdiff-backup works. The diffs are _reverse_ diffs, working
back from the current state. Any metadata or increments file with a date
stamp older than the cutoff date can be simply deleted. I suspect that the
problem is the time spent parsing all of the file names in the _huge_
increments directory tree and comparing the date code.

Speaking the the huge increments tree, a pet peeve of mine is that changes
that do not affect file content cause a "zero diff" file to be generated.
These can be changes to permissions and ownership, or even just a change
to the hard link count. The files are typically compressed empty files,
and are not empty themselves (there is at least a gzip header). I run an
audit to get rid of most of these at the end of each day, after all
clients have completed their backups. The first time I ran it, the count
was well into the millions.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.