rsync - Aug 2011 - Purpose of --checksum-seed ?

I'm trying to understand the point of the --checksum-seed option.  As I 
understand it from a little reading, checksums are not cached over 
executions of rsync.  So...what is the point of fixing the seed?

Is this in support of patches which *do* support caching of checksums?  
I've read about caching these in files and in xaddr.  Is there a "best 
solution" for caching checksums?

I'm asking because one particular volume, when I added the --checksum 
option, went from 11m37.520s to 290m22.423s.  If I could cut that down, 
this would be a good thing.

On the other hand, the reason I'm switching to checksum as opposed to the 
timestamp approach is to catch files that people are deliberately 
"backdating" to avoid the changes being seen.  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).

I guess I'm vague on a lot of the ideas around the of checksums.  
Enlightenment would be welcome.

Thanks...

	Andrew

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>