Heya !
It seems that we found it out. It's the partial flag. We tested a lot of stuff
here with strace and could see that after some while there came timeouts
on some descriptors (0 = stdin). We saw that after those timeouts got
heavy the blocks-in-out dropped heavily. But the reason wasn't clear
at first. And so we tried to search with iptraf and found the problem.
If you have a big file that got transmitted only 50%, the rsync process
on the other side just copy the data that's still there to another file:
.file-strangestring
This copy lasts a long time on big files. The bigger the file, the longer
the wait on the sending side until it really can send something. It seems
as if the sending side after some while is getting a hard timeout. After this
big and last one the speed drops extremely to 700 KB/s or even less. It
looks like a busy loop because the rsync process eats all of the CPU time
on the sending side without actually sending much.
I'd call it a bug. But maybe we're the first ones that tried to send that
lot of data in one file...
The workaround is: if you have big files, just don't use -p or --partial.
Even this can lead to problems: when the file is already there it seems
to do --partial anyway. Maybe it's just a bug in the 2.5.6cvs-version or
maybe this is what --force is to be for ?
Now we have a constant rate of 13 MB/s. This isn't much on a Gigabit-line
but it's sufficient for our needs.
Thanx to all of you.
Mermgfurt,
Udo
--
Udo Wolter | /"\
email: [EMAIL PROTECTED] | \ / ASCII RIBBON CAMPAIGN
www: www.dicke-aersche.de | X AGAINST HTML MAIL
dark: [EMAIL PROTECTED] | / \
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
