Purpose of --checksum-seed ?

[Wayne Davison]

On Wed, Aug 10, 2011 at 3:19 PM, Andrew Gideon <c182driver1 at gideon.org>wrote:

> So...what is the point of fixing the seed?
>

I'ts not really intended for normal use.  It can help with some types of
debugging and other fringe uses.

Is there a "best solution" for caching checksums?


For use with user-changeable files (as apposed to things like mirror files
that don't change in unpredictable ways), my favorite patch is db.diff -- it
allows you to cache checksums in a SQLite or MySQL db.  If you copy files
to/from temporarily-mounted filesystems, you will need to update the "disk"
table to match the mounted devices each time that changes or just leave out
the temp-mounted disks (which will just not cache checksums associated with
a missing disk device number).  If your mounts don't vary, a single-time db
init via the perl script is all you need (perldb --db=foo.cfg --init
--mounts).

I also recommend using the mysql db support unless you're just trying things
out, in which case the SQLite support can be somewhat useful.  The SQLite DB
likes to do a lot of exclusive locking, and so it is pretty slow when
writing lots of checksums.  It can also not play nice with a local transfer
where you want both the sender and receiver to be querying and updating the
DB at the same time.

Note also that each side of the transfer needs its own --db option, which is
why the patch expects the --remote-option (-M) patch to be applied first.
 e.g. rsync -aiv --db=/etc/db.cfg -M--db=/etc/db.cfg src/ dest/

I'm unclear how caching checksums doesn't cause exactly that problem (since
> a cached checksum means that the file isn't checked for changes each time
> rsync runs).
>

This works because the caching makes a note of the file's ctime (in addition
to size and mtime), which is something like an inode change time.  Any
change to a file (data or otherwise) will affect the file's ctime, and the
ctime can't be manually set. The caching patches will re-compute the file's
checksum if the ctime has changed, just in case the data has changed (and,
if the patch saves the info, like db.diff does, it will then note the new
ctime when caching the checksum).  Sadly the code doesn't yet save & compare
sub-second timestamps (for those filesystems that support that).

..wayne..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20110810/617811bd/attachment.html>