Need hint for my question regarding the working of rsync.

[Patrick Pollen]

>>  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 <kmk at 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 <kop at 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.               Kevin at FutureQuest.net  (work)
>         Orlando, Florida                kmk at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/rsync/attachments/20131113/af68302e/attachment.html>