Rsync --delay-updates takes a long time

Eric Horne eric at
Sat Jul 8 17:46:57 GMT 2006

Wayne Davison wrote:
> On Sat, Jul 08, 2006 at 08:07:43AM -0700, Eric Horne wrote:
>> It seems that once the transfer is complete, --delay-updates takes a 
>> really long time to copy data.
> The only file movement that --delay-updates supports is renaming -- it
> never re-copies the files.  Perhaps your OS (or filesystem) is doing
> something strange with the rename() system call?
Hmm..  I looked at it again, and it isn't the --delay-updates (as you 
pointed out). Something inside of rsync is running through each file, 
after the files have been transferred. I see now that --delay-updates is 
doing a "rename". Just before the renames, though, rsync reads all the 
files in the partial-dir that I've specified. It doesn't appear to be a 
network transaction with the client rsync. I wonder if maybe it is a 
last-minute checksum calculation or something to verify the files were 
transferred correctly? I see a ton of read() statements.

It is these reads that appear to be causing the delay.. rsync spends 
more time than allocated in the timeout reading all the files it just 
transferred. I just don't know why they are there and if there is a way 
to turn them off or make them faster?

I've been playing around with using a temporary directory, but the only 
solution I can think of is to use a temporary directory AND partial-dir 
inside local space, which breaks the partial-dir (because partial-dir 
and the target are on separate file systems, can't merely rename them). 
Using a temporary directory alone is only good for one file at a time.

Maybe I should be looking at linux -> solaris NFS performance instead of 
trying to making rsync jump through hoops..

Thanks so much for your help! If you have any suggestions or ideas, I'd 
sure love to hear them!


More information about the rsync mailing list