-----BEGIN PGP SIGNED MESSAGE-----
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
sent.
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 <k...@meme.com> Free Software: "You don't pay back, you pay
> forward." -- Robert A. Heinlein
>
- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. ke...@futurequest.net (work)
Orlando, Florida k...@sanitarium.net (personal)
Web page: http://www.sanitarium.net/
PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKDzNMACgkQVKC1jlbQAQeQmgCgv2EzGq63Mct0pOj87xYMdKvo
afIAoMT6KZUj7oL/44PURsoByf2SPc7R
=uCwx
-----END PGP SIGNATURE-----
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
