using rsync 3.0.0 CVS version

[Paul Slootman]

On Sat 27 Jan 2007, Wayne Davison wrote:

> I had not encountered this hang until today.  The backtrace implicated
> a problem in the wait_for_receiver() routine, and I figured out that
> every now and then the io_flush() call could end up reading the last
> available message from the receiver, giving the read_msg_fd() call
> nothing to read (causing a deadlock).
> 
> I checked in a fix for this and released a new "nightly" tar file.

Unfortunately the current CVS version (updated a couple of hours ago) still
hangs :(
The directory structure I reproduce this with is an image storage for an
classifieds site (comparable to Ebay, but no auction stuff).

The images are stored according to the ad number, e.g. 10473158 is
stored as .../images/10/1047/10473158_[1-9]_{thumb,detail,list,etc}.jpg
Currently in the images/10/1047/ directory there are more than 20000
files. Using the old rsync, it can take up to 12 hours to traverse one
of the top 90 directories. It's an ideal candidate for the new
incremental list thing...

Just now, with various straces running, the sending process got to:

lstat("1037/10379999_1.jpg", {st_mode=S_IFREG|0664, st_size=10187, ...}) = 0
lstat("1037/10379999_1_detail.jpg", {st_mode=S_IFREG|0664, st_size=4082, ...}) = 0
lstat("1037/10379999_1_list.jpg", {st_mode=S_IFREG|0664, st_size=919, ...}) = 0
lstat("1037/10379999_1_thumb.jpg", {st_mode=S_IFREG|0664, st_size=1269, ...}) = 0
select(5, [4], [], NULL, {60, 0})       = 1 (in [4], left {60, 0})
read(4, "\4\0\0kW\206\r\0\4\0\0kX\206\r\0\4\0\0kY\206\r\0\4\0\0"..., 8184) = 96
select(5, [4], [], NULL, {60, 0})       = 0 (Timeout)
select(5, [4], [], NULL, {60, 0})       = 0 (Timeout)
...

and then remained waiting in select().



Paul Slootman