Need hint for my question regarding the working of rsync.

Kevin Korb kmk at
Wed Nov 13 12:02:43 MST 2013

Hash: SHA1

To an extent it is serially.  The sender tells the receiver what it
needs to stat().  However, thanks to incremental indexing it will
parallelize but the receiver will not go beyond what the receiver has

Read the --recursive section of the man page for more information as
well as a list of the options that disable it and force it to be
purely serial.

On 11/13/13 13:59, Karl O. Pinc wrote:
> On 11/13/2013 12:03:21 PM, Kevin Korb wrote:
>> OK, in the case of using v3 with --link-dest and not --checksum
>> most of the initial activity on the sender would be doing calls
>> to stat() to index what is there.
>> The receiving side would be doing 2x the stat() calls (you have
>> 2 --link-dest dirs for it to check) and link() calls every time
>> it finds a matching file.
> Am I correct in my impression that the sender and receiver are
> doing the above serially, not concurrently?
>> stat() is an expensive call in terms of time spent (especially
>> when multiplied by millions of files) but it doesn't really
>> translate into much disk IO since it is such a small amount of
>> actual data.  The link() call is pretty much the same except it
>> is a write op instead of a read op.  So, you wouldn't show much
>> MB/sec usage of your disks until rsync found a new or different
>> file but there would be many small operations.
> My thought is to save wall time by increasing concurrency.
> No doubt there are tradeoffs involved.  If forced to choose between
> features what I really want is entirely different; for -H to have
> "priority" over --link-dest so that when the fs surpasses its
> hardlink limit the end result is that the -H links exist and the
> --link-dest links do not.  Future --link-dest operations would then
> work and, most importantly, the result of the running rsync
> operation would be a good copy of the source.  This would allow 
> many --link-dest-ed backups of a fs used by hardlink-happy
> applications.  (Like yum.)
> Karl <kop at> Free Software:  "You don't pay back, you pay
> forward." -- Robert A. Heinlein

- -- 
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at  (work)
	Orlando, Florida		kmk at (personal)
	Web page:
	PGP public key available on web site.
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -


More information about the rsync mailing list