>> These are both a weak and a strong checksum for each chunk of the file from start to finish.
So lets take an example. If a file were 70000 bytes and the logical block size for rsync by default being 700, it would send : 1) 4 Bytes x 70000/700 = 400 Bytes 2) 16 Bytes x 70000/700 = 1600 Bytes Total : 2000 Bytes Is this correct ? On Wed, Nov 13, 2013 at 3:55 AM, Kevin Korb <k...@sanitarium.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > First, are you talking about --checksum checksums or the hashing of > files that are different on both ends so that only the differences > need to be transferred? You seem to be talking about the latter while > describing the performance of the former. > > If you are talking about --checksum then you should know that it is > only there for a few very unusual use cases. It most normal(ish) use > cases --checksum is slower than simply re-copying everything and > especially re-hashing everything (--ignore-times). > > On 11/12/13 17:13, Karl O. Pinc wrote: > > On 11/12/2013 03:50:20 PM, Wayne Davison wrote > > > >> Yes, the receiver sends all the checksums that it generates at > >> once > > > >> For really big files it would be interesting to amend this rule > >> to one where the sending side waits only long enough for a > >> certain number of checksums to arrive before it begins its work > >> (and perhaps pauses if it gets too far ahead of the arriving > >> checksums). > > > > Based on the behavior I see when using rsync, without really > > knowing what's going on, it seems that the sending side first does > > a lot of disk access, then the receiving side does, and then the > > sync begins over the network. It would save a lot of wall-clock > > time if the sending and receiving side could both be hitting the > > disk at once. At least in my use case, with whatever version of > > rsync I happen to be using. > > > > > > 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/ > > iEYEARECAAYFAlKCqvEACgkQVKC1jlbQAQdV4wCghWzsier+l7/Q5QMLr3HqSJ+m > enAAn1gBX9zULkpDqArhbhKl34xnAmRr > =FzIv > -----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 >
-- 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