[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discussion about file format for the future

From: rhkramer
Subject: Re: Discussion about file format for the future
Date: Tue, 9 Jun 2020 16:51:43 -0400
User-agent: KMail/1.13.7 (Linux/3.2.0-6-amd64; KDE/4.8.4; x86_64; ; )

On Tuesday, June 09, 2020 12:30:24 PM Robert Nichols wrote:
> 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. 

Ahh, ok, thanks!  (Now I know something about rdiff-back ;-)

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]