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

[foner-rsync at media.mit.edu]

    Date: Mon, 2 Jul 2007 21:18:57 -0400
    From: "Matt McCutchen" <hashproduct+rsync at gmail.com>

    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.