Problem using rsync for backing up on to a NAS

[Matt McCutchen]

On Sat, 2008-09-06 at 08:22 -0700, Wayne Davison wrote:
> On Mon, Aug 25, 2008 at 04:43:29PM +0200, Thomas Ebert wrote:
> > rsync: stat 
> > "/home/thomas/DiskStation/Thomas/backup/molungus-root/2008-08-25/usr/share/terminfo/L/LFT-PC850" 
> > failed: No such file or directory (2)
> > usr/share/terminfo/l/lft => usr/share/terminfo/l/lft-pc850
> > rsync: link 
> > "/home/thomas/DiskStation/Thomas/backup/molungus-root/2008-08-25/usr/share/terminfo/L/LFT-PC850" 
> > => usr/share/terminfo/l/lft-pc850 failed: File exists (17)
> 
> This indicates that your filesystem is not behaving correctly, since it
> is returning conflicting results to rsync.  One of your pastebin errors
> from an earlier email also listed an NFS error with a mount going stale,
> which is something that you'd need to fix outside of rsync.
> 
> > File index not found: 7235938 (-1 - 185115)
> > rsync error: protocol incompatibility (code 2) at hlink.c(488) 
> > [generator=3.0.3]
> 
> That looks like some kind of text message getting in the way of the
> protocol, since the number turns into the string "bin".

Wayne, I am not convinced at this point that the problem is entirely the
filesystem's fault as opposed to rsync's.  It's possible that odd
behavior in the filesystem is triggering an improperly handled case in
rsync.  The "bin" is harder to explain as an external insertion than the
"Kill" we saw earlier; it could be rsync's own data that is
misinterpreted as a file index after the protocol gets out of whack.
I'm also wondering why rsync is trying to populate
usr/share/terminfo/l/lft-pc850 from a link-dest file that differs in
case.

In any case, Thomas, what would help us get to the bottom of the problem
would be if you could find the smallest rsync run that exhibits the
problem (e.g., copying just /usr/share/terminfo) and then strace rsync
so we can see exactly what syscalls it is issuing and how the filesystem
is responding.

Matt