-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I can see --checksum being faster on a slow link. This is because
- --ignore-times has to send more checksums than --checksum does. This
is why more data was transferred even though no files were actually
transferred.
On 03/02/12 12:57, Joachim Otahal (privat) wrote:
> Nope.
>
> Available line speed: Sending 5 MBit, receiving 6 MBit. "real"
> line speed - well, it is a VPN over Internet, very "controlled"
> speed...... All files are already sync.
>
> Fileset: about 3.31 GB, 3146 files, several runs. min time/max
> time/mean time
>
> rsync -rtvvzPc --compress-level=9 --fuzzy --delete-delay
> 192.168.250.68::d/bootcd/ /cygdrive/e/bootcd/ sent 10497 bytes
> received 145562 bytes 2039.99 bytes/sec total size is 3559041255
> speedup is 22805.74 75.4/96.3/80.8 seconds
>
> rsync -rtvvzP --ignore-times --compress-level=9 --fuzzy
> --delete-delay 192.168.250.68::d/bootcd/ /cygdrive/e/bootcd/ sent
> 8885025 bytes received 207541 bytes 33613.92 bytes/sec total size
> is 3559041255 speedup is 391.42 182/250/195 seconds
>
> -c wins clearly over --ignore-times, about 5:2 (more or less).
>
> --ignore-times would win if: some files with large size, change
> every time they are synced, but only 'cause -c only saves time on
> files that are already snyc. In my sync case > 95% of the files are
> already sync (except for my testing when everything was sync).
>
> regards,
>
> Joachim Otahal
>
> Kevin Korb schrieb:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Try --ignore-times instead of --checksum. It will appear to do
>> more since it will actually re-delta xfer everything but in my
>> experience that is faster than --checksum almost all of the
>> time.
>>
>> On 03/02/12 02:07, Joachim Otahal (privat) wrote:
>>> Kevin Korb schrieb:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> I am not much of a programmer so I know I could never take
>>>> over rsync development but if I could boss such people around
>>>> here are the new directions I would take:
>>>>
>>>> 1. --itmize-changes is eliminated and becomes part of
>>>> --verbose
>>> 100% agree there.
>>>
>>>> 5. I am almost tempted to say I would remove --checksum
>>>> because 95% of the times I have seen someone using it they
>>>> did so to their own detriment. But I have seen at least 2
>>>> actual valid use cases for it to exist so I would only add an
>>>> extreme disclaimer to the man page
>>> Naaa, please not. I rsync some sets across a slower VPN line,
>>> and due to different OS-es and filesystems on both ends I
>>> cannot rely on things like timestamp. Checking filesize changes
>>> is not enough, since quite some files (a few hundred of several
>>> thousands) change without changing the size, and less than ten
>>> files (but too many to ignore) get modified without changing
>>> the (a|c|m)time. This leaves me the last resort -c to make 100%
>>> sure every change is detected, but only changed files are
>>> synced.
>>>
>>> If -c would not exist I would be forced to use something
>>> completely different, first sync "the usual way" based on
>>> filesize and timestamp. I would not need rsync for that,
>>> simpler tools which don't require a daemon can do the same. And
>>> in a second run do a crc32 (or md5 whatever) recursive, check
>>> for crc differences and transfer those which crc's still
>>> differ. Would work, but ugly. -c is better and my absolute
>>> winner.
>>>
>>>> Unfortunately I know that such fundamental changes would
>>>> create a backlash. So maybe I wouldn't actually do them if I
>>>> had the authority. But I am pretty sure they are all a good
>>>> idea.
>>>>
>>>> and of course now we are way beyond the scope of your
>>>> question and into the realm of the opinion of someone who has
>>>> been using rsync as the low level tool of a backup system for
>>>> more than a decade and who regularly helps out on #rsync.
>>> Oh yes indeed, your answers show a lot of experience fighting
>>> with/against the rsync dragon.
>>>
>>> Joachim Otahal
>>
>
- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
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.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9RC0QACgkQVKC1jlbQAQckPACg1QZiLcdM2LAv5xRp6Dhi6G+J
ltcAmwVjj4RboFgIu/bwHJbIcYFR3w3b
=/0Nq
-----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
