Hi,
even if it's not the inodes, it might be any kind of metadata
(ownership, time, access rights, etc). I could for example imagine that
the LVM snapshot is readonly, which would make rdiff-backup consider
that there is a change, as Leland already stated.
This said, if you consequently use the LVM snapshot, I would assume that
it'll remain a one time effect.
KR, Eric
On 08/02/2022 05:25, Robert Nichols wrote:
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.
