Date: Mon, 2 Jul 2007 21:18:57 -0400 From: "Matt McCutchen" <[EMAIL PROTECTED]>
The technique Wayne and I are discussing assumes only that the clock on *each side* never steps backwards. It compares the current mtime and ctime on each side to the previous mtime and ctime on that side as recorded in the cache. Clock synchronization between the two sides is irrelevant. Okay, but that's still unreliable. Backward clock steps -can- happen; only in Multics is it (mostly) impossible (because a backwards step would destroy the filesystem). But since rsync probably doesn't run on Multics... :) Consider a much more likely scenario---an NFS server reboots. It's perfectly okay for it to do this at any time, and the client NFS will recover, without informing rsync. It's quite possible for large clock steps to happen upon reboot, especially for machines that might run ntpdate on boot but not ntpd during normal operation. In that case, you've got about a 50% chance that there might be a backwards clock step, and this could conceivably happen between any two NFS requests... It is true that if either side's clock steps backwards, that side could be fooled into thinking a file hasn't changed from the cache when it really has. There's very little we can do about that except tell the sysadmin to delete all the caches when he/she sets the clock backwards. > Seems to me the only way around this would be to do the touch before > -every- file you handle, which doubles the amount of statting going > on, etc. And there are probably still timing windows there. I don't understand this concern. If you'd like a more formal proof that the technique never misses a modification assuming each side's clock runs forward (actually, just each filesystem's clock), I would be happy to provide one. Working out such a proof would be interesting (because it might reveal a flaw nobody's even thought about yet), but the first order of business might be figuring out how to reliably detect a backwards step, or how to make sure that users understand they might be silently screwed if one happens. I understand that it's a fairly low probability, and depends on some questionable configurations, but rsync is well-known to be both reliable and deterministic. I'd hate for something like this to start chipping away at that reputation, even if we -are- talking about a corner case in a performance optimization that might not get invoked all that much. Not that my opinion in this matters a whit to begin with; I just thought I'd point out a possible screw case before it actually screwed someone. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html