Detection of permission changes

Kevin Korb kmk at sanitarium.net
Fri Mar 2 11:02:44 MST 2012


-----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.		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.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9RC0QACgkQVKC1jlbQAQckPACg1QZiLcdM2LAv5xRp6Dhi6G+J
ltcAmwVjj4RboFgIu/bwHJbIcYFR3w3b
=/0Nq
-----END PGP SIGNATURE-----


More information about the rsync mailing list