--timeout not honoured

[Wayne Davison]

On Fri, Dec 18, 2009 at 4:29 AM, Fabian Cenedese <Cenedese at indel.ch> wrote:
> 13:18:52 write(4, "\367\344\356\325UUM3\273*<17\7\256D\255\225x0\345^{\203"..., 4092) = 4092
> 13:18:52 time(NULL)                     = 1261138732
> 13:18:52 select(5, NULL, [4], [4], {60, 0}) = 0 (Timeout)
> 13:19:52 time(NULL)                     = 1261138792
> 13:19:52 write(2, "io timeout after 9720 seconds --"..., 40) = 40

That looks like it's the sending side.  It appears that the sender
writes out a bunch of data to the socket (fd 4), does a select
attempting to write more data, and when that times out after 30
seconds, the lack of any reads since the start of the rsync process
causes rsync to time (this is because rsync currently bases its
timeout on last reception of data).

Sadly, the I/O code in 3.0.x (and 2.x) does not have the sender
attempt to read data from the generator while it is trying to output a
bunch of data, so even if the generator sent a keep-alive message to
the sender, the sender was not even trying to read it.  Thus, if the
NAS is so slow that the sending side ever pauses for 30 seconds
waiting to output more data, it may timeout inappropriately.  This
situation will be fixed in the (future) 3.1.0 release, which has a
much-improved I/O setup.

In the meantime, you might try using --bwlimit, but if that doesn't
help (or is undesirable), you may need to either stop specifying
--timeout, or switch the client side to using the latest git (or
nightly) 3.1.0dev release.

The 3.1.0dev release should avoid the timeout issue even when it is
sending to an older rsync, since its sender will (#1) pay attention to
the generator, and (#2) assume that any I/O over the socket is good
I/O, and not timeout if I/O is succeeding.  The 3.1.0dev code is
looking good so far, but may yet contain some errors that need to be
shaken out.  Care should be taken when using it.  I will also see
about a simple fix for the upcoming 3.0.7 release, which may be a
better choice for you in the near term.

..wayne..