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

Matt McCutchen hashproduct+rsync at gmail.com
Tue Jul 3 02:34:52 GMT 2007


On 7/2/07, foner-rsync at media.mit.edu <foner-rsync at media.mit.edu> wrote:
> 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.

You needn't worry: there's no question in my mind that --checksum
should continue to mean "read every file every time and calculate the
checksum anew" for those who need to be 100% certain (modulo checksum
collisions) that the file data is the same on both sides or suspect
that something is wrong with the clock.  However, for general use, a
checksum cache is still considerably more robust than the current
default size-and-mtime quick check, so I think rsync should offer it
via a separate option (perhaps --cached-checksum).

I believe that the administrator of an rsync daemon who doesn't want
clients bogging it down unnecessarily should be able to configure it
so that --checksum means --cached-checksum.  If you don't like this,
consider that clients have always gotten whatever data the
administrator chooses to give them; by enabling this setting, the
administrator is merely choosing to give them a slightly cached
version of the data in the filesystem rather than the actual data.
Compulsively honest daemon administrators could refuse --checksum
instead.

Matt


More information about the rsync mailing list