Re: [rdiff-backup-users] Suggestion for documentation change

[dean gaudet]

On Sat, 18 Nov 2006, Andrew Ferguson wrote:

> dean gaudet wrote:
> > sounds like the bug is that rdiff-backup decides there's a metadata change 
> > and stores an almost-empty .diff.gz file even though it's not required.  
> > even though the metadata change is innocuous...
> 
> I think there could be a reason for the almost-empty .diff.gz file, but
> it depends on whether we view metadata changes as true changes to a
> file. That is, do we truly want to see that a file 'changed' at a
> specific backup time, or do we just want that implicit in the metadata?
> 
> This is connected to the fact that you can do restores with rdiff-backup
> of the form:
> 
> rdiff-backup
> /backup/rdiff-backup-data/increments/path/to/file.<time>.diff.gz
> /path/to/file
> 
> If we stop creating the .diff.gz files for metadata-only changes, we
> break this behavior for the case when you want to restore on one side or
> the the other of a metadata-only change.
> 
> Does this make sense?

yep -- but we could store an actual 0-length file instead... so we're not 
wasting an entire disk block on many filesystems.  better to name it 
.nodiff or something else so we can distinguish between an incompletely 
written .diff.gz and a file with no differences.

there's another case of frequently changing metadata -- if you backup from 
an LVM snapshot the device number changes now and then (because it's 
dynamic).  the inode remains the same... this used to cause me a lot of 
disk space wastage but i stopped using LVM and so the problem dropped in 
priority for me.

-dean