Hi Libor!
Thanks for your hint!
In fact using rsync via ssh as workaround *does work for me*, too.
This indeed adds an extra performance penalty for the SSH tunneling, but
in my final setup SSH will be required anyways.
In fact this issue seems to occur mainly with slow rsync servers like
NAS. I'd rather assume it's some network timing issue, because I was to
able to observe a continuous stream of checksums until the point of
error. Maybe some network tasks on the NAS starves to death due to the
high load of the rsync daemon?
Thanks to you for the helping tip and to the rsync Team for this this
great tool!
- Ben
Am 16.10.2012 12:16, schrieb Libor Klepáč - libor.kle...@bcom.cz:
Hello,
i was dealing with same thing , I coudln't find a sollution using rsyncd.
Using rsync+ssh did the trick ...
Problem was (probably) with slow NAS, taking ages to compute (initial?)
checksums of target file.
When using --progress or --verbose, it was just sitting there without
output, but spinning CPU hard on NAS side, then timeout (even with
timeout set to 2 hours)
Rsync over ssh does the same thing, but it doesn't timeout ...
https://lists.samba.org/archive/rsync/2012-August/027769.html
With regards
Libor
--
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
