Hi Kevin, On Thu, Feb 03, 2022 at 05:38:41PM -0500, Kevin Korb via rsync wrote: > Are you using the same source and target each time?
Yes. > I ask because the only discrepancy I see is the link count which > shows that there are 11 more instances of that inode on the source > than the target. Maybe instances in other snapshots are being > updated/re-linked? I haven't yet let rsync run all the way through the whole source filesystem so it probably hasn't yet sent over some of the hardlinks that it knows about for this file. There's only ever one rsync going at once, because this is a one-off thing I am doing by hand. > The only other thing to mention is that when you abort rsync (with -P or > --inplace) incomplete files are left. Rsync doesn't fix the owner+group > until it is done with a directory and it doesn't fix the timestamp until it > is done with a file. This would be why you shouldn't mix those options with > --update since the truncated file will be newer than the source file. Okay, but: - it's thousands of files that are reported as having differing t/o/g, not just whichever one was being worked on when I hit ctrl-c. I'm only hitting ctrl-c because rsync sees thousands of changes that I can't explain. - they don't have differing t/o/g when you look at them. - their contents are identical anyway as confirmed by sha256sum and also as confirmed by the fact that rsync isn't sending the file contents over. - if I use "-I --checksum" to skip mtime checking and force checksum, rsync doesn't try to sync these files (it does still for the ones it thinks o/g are different). This partial workaround isn't very useful anyway as --checksum takes forever. Point is, it definitely thinks there are changes of mtime, uid and/or gid. So I am still really confused. If I remove the --inplace I think the spurious t/o/g detection will still happen, and also that rsync will create a temp file to rename over each file, so blowing up the hardlinks that it has already sent across. This would be mere curiosity if it did this once and then was happy that it had set the mtime/uid/gid, but it doesn't, it does it every time, which is making things really slow. I am trying to build a newer rsync for use on the sender to see if that makes any difference but am also running into bizarre problems there, which is perhaps for another thread. Illegal instruction somewhere inside libcrypto. The same libcrypto that the packaged rsync is linked against. Goes away if I use --cc=none, but happens for md4 or md5. Really not my night! I am tempted to blow away the btrfs filesystem and just do xfs to xfs, to rule out weird issues there. It would be a shame though as I was hoping to use btrfs's compression here. Cheers, Andy -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
