On 2/7/22 7:23 PM, Leland Best wrote:
Hi Cliff,
On Mon, 2022-02-07 at 11:45 -0800, Mr. Clif wrote:
Hey Eric,
any ideas on this? How do these diff files normally work?
[...]
I'm not an 'rdiff-backup' developer or anything so all you experts
out there
correct me if I'm wrong but ...
IIRC 'rdiff-backup' keeps inode info as part of the metadata for each
file.
When you mount a filesystem Linux assigns "fake" inode numbers to avoid
collisions between filesystems on different devices/partitions/etc..
So if you
change the mount point, every file could potentially get a new inode
number and,
consequently, have changed metadata. That results in 'rdiff-backup'
creating a
'*.diff*' file for every source file.
Device and inode metadata is kept only for files with multiple hard
links. That's
to keep track of which links reference the same file. That information
is not
needed for files with just a single hard link, and unless something
has changed
in the latest release that metadata is not kept. You can look in the
mirror_metadata file (it's compressed ASCII) and see what fields are
present
for each file.
In addition, since 'rdiff-backup' now thinks the files may have
changed it
spends a lot of time checking if anything other than metadata has
changed which
_might_ account for the apparently low throughput.
That would definitely be true, and the presence of all those "zero
diff" files
show that it is, in fact, happening.