Re: [rdiff-backup-users] atomic increment files?

[Marcel (Felix) Giannelia]

> Yup, and you'd have to guarantee that the journal is written to disk 
> on the remote side, and you'd have to work out how to back-out the 
> journal/archive if they were ever out of sync.
>
> Basically, you'd turn rdiff-backup into (rdiff-backup + journaling 
> filesystem).... so why not just use the existing journaling 
> filesystem? :-)
>
> That's my real argument against your proposal: it makes rdiff-backup 
> much more complicated in order to make a few operations faster (and I 
> don't feel the tradeoff is worth it). Operations which better tools 
> (ie, "not du") can do better.
du wasn't really the problem, just a handy example -- any tool that had 
to enumerate the files was running dead slow. I see your point about 
complexity though, and I'll see if I can think of a better solution 
(since I really do need a way to clean up old backups that doesn't 
involve deleting them).
> Unfortunately, --remove-older-than is more complicated than that. It 
> also has to transform the last remaining increment into snapshots, as 
> opposed to reverse-deltas. That would be a nasty operation if all of 
> the increments were in archives. (remember, rdiff-backup mostly stores 
> the increments as reverse-deltas.)
I'm missing something important here -- why does the last increment have 
to become a snapshot? Isn't the restore procedure just "start with the 
mirror file, then apply patch after patch until we get to the right file 
version"? Also, wouldn't turning all of the last remaining increment 
into snapshots double the size of the mirror (since you'd have the "now" 
mirror, and the "farthest back in time snapshot" in the 
rdiff-backup-data dir)?

~Felix.