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
--
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
