<div class="gmail_quote">On Wed, Dec 28, 2011 at 4:04 AM, Simo Melenius <span dir="ltr"><<a href="mailto:simo.melenius@iki.fi">simo.melenius@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>However, checksumming big files (even dozens of gigabytes) takes time. Now, I observed that my files never really change only little and in only some parts. Also, undetected corruption is not an issue here: I can survive that by other means.</div>
</blockquote><div><br></div><div>Check out the various checksum* and db patches in the patches distribution.  They provide a way to cache the checksum for files that haven't changed.  They work based on the idiom that the ctime for a file will change even if the mtime gets set back to an older value.  When the ctime changes, rsync recomputes the checksum.  For all other files, the cached checksum suffices.</div>
<div><br></div><div>Ignore the checksum-xattr.diff patch, as that just provides a way for a server/mirror host to cache the checksums for files -- it doesn't provide a safe way to detect when a new checksum is needed.</div>
<div><br></div><div>The checksum-updating.diff patch is a reasonable solution, as long as you don't mind a bunch of .rsyncsums files getting sprinkled about (it requires the checksum-reading.diff patch).</div><div><br>
</div><div>Finally, the db.diff patch stores its checksums in a database.  It supports MySQL and SQLite3 (though the write speed on the latter needs to be improved).  The db patch doesn't currently handle expiring orphaned checksum entries from the db yet, though.</div>
<div><br></div><div>As for the sparse checksumming, feel free to send me a patch -- I'll consider putting it into the patches release.</div><div><br></div></div>..wayne..<br>