DO NOT REPLY [Bug 5695] improve keep-alive code to handle long-running directory scans

samba-bugs at samba.org samba-bugs at samba.org
Thu Apr 9 22:49:43 GMT 2009


https://bugzilla.samba.org/show_bug.cgi?id=5695





------- Comment #4 from wwendin at sbcglobal.net  2009-04-09 17:49 CST -------
I echo the "thanks for all your hardword making rsync available to the masses".

I'd just like to add to this defect that I have a system where disk writes can
be very slow when my client is very loaded.  In my system, rsync gets lowest
priority to use disks on the client.  Some very large files in my directories
can take a long, long time to create (longer than the 10 minute timeout I need
to use on client).  I am not using --copy-files but I am getting a local copy
because my very large files are often mostly unchanged (just a byte in a
gigantic file) or only a timestamp change.   So the receiver is creating the
temp file from an existing file which is usually 100% or 99.999999% the same.  
I am stuck in the file creation loop in receiver.c/fileio.c for more than 10
minutes because write() is slow but it does make slow progress.

Just for fun, I simulated my problem on a fast Linux client by hacking in a
msleep(20*1000) in the flush_write_file() loop on the client rsync so that each
local file "copy update" takes much longer than the client timeout.  The server
times out on the client in this test scenario too.

I would love it if someday you could make a keep alive, or equivalent, for file
creation and not just for directory listing.  I'll do a workaround by making a
huge timeout on the server /etc/rsyncd.conf so that it does not timeout on the
client.

By the way, here is my rsync command line; nothing fancy here except the
timeout.  Yes, I'm using a slow FAT drive (I have no choice here):
rsync --modify-window=3602 -ptO -L --delete-during -v -ii --progress --port=
873 -z -r --bwlimit=0 --timeout=600 "myserver::rtdata/mydir" "destdir"


-- 
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.


More information about the rsync mailing list