Kevin Korb via rsync <rsync at lists.samba.org> (Mi 14 Mär 2018 14:52:55 CET):> Your observation would be right if you are using --checksum which you > shouldn't be. Otherwise, unless you are using --whole-file rsync will > use its differential algorithm to compare the files. If you are using > --progress you will see it step through the file at a faster speed thanOk, Thank you. I'll try to find the options they're using. But, anyway, even with --checksum, why can't it run and checksum the file on both sides in parallel? If I understand your answer, then it does it in sequence, doesn't it? -- Heiko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.samba.org/pipermail/rsync/attachments/20180314/e1fd3256/signature.sig>
Do not use --checksum. It has an extremely limited use case. Normally it is much slower than simply re-copying everything. --checksum means checksum every file on both ends (even files that only exist on one end) before doing anything else even if doing so causes a timeout failure. --checksum is the only part of rsync stupid enough to leave one end idle potentially for hours. On 03/14/2018 10:14 AM, Heiko Schlittermann via rsync wrote:> Kevin Korb via rsync <rsync at lists.samba.org> (Mi 14 Mär 2018 14:52:55 CET): >> Your observation would be right if you are using --checksum which you >> shouldn't be. Otherwise, unless you are using --whole-file rsync will >> use its differential algorithm to compare the files. If you are using >> --progress you will see it step through the file at a faster speed than > > Ok, Thank you. I'll try to find the options they're using. > > But, anyway, even with --checksum, why can't it run and checksum the > file on both sides in parallel? If I understand your answer, then it > does it in sequence, doesn't it? > > >-- ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., 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. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._., -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 224 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/rsync/attachments/20180314/864aca4d/signature.sig>
Kevin Korb via rsync <rsync at lists.samba.org> (Mi 14 Mär 2018 15:25:56 CET):> Do not use --checksum. It has an extremely limited use case. Normally > it is much slower than simply re-copying everything. --checksum means > checksum every file on both ends (even files that only exist on one end) > before doing anything else even if doing so causes a timeout failure. > --checksum is the only part of rsync stupid enough to leave one end idle > potentially for hours.They just use --partial --numeric-ids and have the „feeling“ that the local i/o load stays low while the remote side has high i/o. I'll try to build a reproducer. Best regards from Dresden/Germany Viele Grüße aus Dresden Heiko Schlittermann -- SCHLITTERMANN.de ---------------------------- internet & unix support - Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} - gnupg encrypted messages are welcome --------------- key ID: F69376CE - ! key id 7CBF764A and 972EAC9F are revoked since 2015-01 ------------ - -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.samba.org/pipermail/rsync/attachments/20180322/62fb485d/signature.sig>