Rsync --delay-updates takes a long time
Eric Horne
eric at box11.org
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!
-Eric
More information about the rsync
mailing list