checksum-xattr.diff [CVS update: rsync/patches]

[foner-rsync at media.mit.edu]

    Date: Mon, 2 Jul 2007 08:43:39 -0400
    From: "Matt McCutchen" <hashproduct+rsync at gmail.com>

    > *Note that "now" for a particular disk may not be the same as time() if
    > the disk is remote, so network filesystems can be rather complicated.

    That's easy to fix: get your "now" by touching a file on the
    filesystem and reading the resulting mtime.

Unreliable.  If you sync up at the beginning of a run, and then the
remote system executes a large clock step (e.g., because it's not
running NTP or it's misconfigured, or it is but NTP has bailed due to
excessive drift from hardware issues or a bogus driftfile (both of
which I've seen*), then "now" might glitch by a second (or more),
which is enough to break your idea of what "now" means---even a
smaller glitch can lead to races based on whose clock ticks first.
Sure, it's a low-probability event, but then, with low probability,
you have some file that isn't getting updated, which can lead to all
kinds of mysterious bugs, etc...

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.

* [One of several ways I saw this happening was a motherboard that
accidentally had FSB spread-spectrum enabled, which caused the clock
to run fast.  NTP gave up slewing and started making larger and larger
steps until it was forced to bail out.  It took quite a while for this
problem to be noticed ("but the machine's running NTP!"), in part
because it took a while to manifest after each boot reset the clock.
Then, when the BIOS setting got fixed, the bad driftfile created by
NTP's valiant attempts to cope with the situation caused the clock
to misbehave in the -other- direction until the NTP conf stuff was
flushed and allowed to regenerate on its own with a working clock.]