Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

[Robert Nichols]

On 12/05/2016 09:28 AM, Joe Steele wrote:
> On 12/4/2016 9:58 AM, Robert Nichols wrote:
> > On 12/03/2016 09:32 PM, Andrea Bolandrina wrote:
> > > What problems does rdiff-backup have with hard linked content?
> > > As far as I know hard links should be supported...
> >
> > Supported?  Yes, but with plenty of bugs.  If links are added and
> > removed from a set, you can end up with two or more separate subsets
> > (i.e., what should be a set of 10 links to a single file becomes 3 files
> > with link counts of 3, 5, and 2), and the link arrangement in the
> > metadata files won't always match the link arrangement in the mirror.
> > The checksum is stored only for the first link in the collating
> > sequence.  If that first link gets deleted, the checksum is lost.  If a
> > link with a path that comes earlier in the collating sequence is added,
> > it sometimes does not inherit the checksum.  I have a massive and
> > time-consuming audit that I run after every backup session to patch that
> > up.
> >
> > Verification always complains about missing checksums for all the links
> > that do no have one stored.  I have to filter out all the verbose 2-line
> > messages for those from the verification report.
>
> I believe the harlink problems you describe are identified in this bug report 
> (that I submitted in 2009):
>
> http://savannah.nongnu.org/bugs/?func=detailitem&item_id=26848
>
> Attached to the report are patches to fix the issue.  Some distros (which I think 
> include Debian, Ubuntu, & Suse) have since been including the patches as part 
> of their packaging.

Those patches look like they address the problems with checksums being misplaced 
or lost, but they don't appear to have anything to do with what I see as the 
greater problem of sets of hard links being broken up and inconsistencies between 
the hard link counts in the metadata and the mirror.  I finally got rdiff-backup 
to build (needed a patch for librsync >= 1.0.0), so I can do some testing later.

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.