two quick conceptual questions RE: rsync (and rsyncing snapshots)

[user]

Chuck - thank you...

On Tue, 1 Nov 2005, Chuck Swiger wrote:

> rsync complains when the filesystem changes underneath it, but it will continue 
> to run.  On the other hand, rsync is not going to safely maintain the 
> referential integrity of a complex file like a live database, but it's okay for 
> most other things including mbox's.


Does it simply complain, or does that somehow alter (lessen) the integrity
of the sync that is going on ?


> > Related: it occurs to me that perhaps it would be better to snapshot the
> > filesystem, mount the snapshot, and then rsync the snapshot.  On the other
> > hand, the filesystem is continuously altering the snapshot as files are
> > destroyed or changed ... so perhaps this does not gain anything.  Is
> > rsyncing a snapshot of a busy filesystem always, ever or never easier than
> > rsyncing the busy filesystem itself ?
> 
> rsync'ing a snapshot is a fine idea.


Ok - because _nothing_ would change, and thus rsync would not complain,
etc.  My gut is that while rsync performance might be increased,
filesystem performance would be about the same, since all destructions and
changes on the underlying filesystem are still being committed to the
snapshot ... can you think of a reason why this would not only increase
the rsync performance, but the overall FS performance while rsyncing ?


> > Finally, am I correct that there are _only two_ rsync comparison methods -
> > the default checksum method, and the --size-only method ?  Am I correct
> > that rsync _always_ looks at the timestamp first, and then applies either
> > checksum or size comparison ONLY IF the timestamps are different ?
> 
> No, rsync checks both timestamp and size or checksum.


So you are saying even if the timestamps are identical, rsync will _still_
do either a size or checksum comparison ?  That seems ... inefficient
?  Is there a way to tell it "if the timestamps are identical, just move
on" ?