search for: wmatthews

...y: poor performance with large block size Product: rsync Version: 2.6.2 Platform: x86 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: wmatthews@sepaton.com QAContact: rsync-qa@samba.org I have a 29Gig file that is the previous version of a file and a 1.3 Gig incremental backup of the file. I did the transfer with no block size option and it takes about 6 minutes (GigEthernet). I used --block-size = 90k and it took about 6 min...

I am trying to understand how match.c works. I am reading the code and something doesnt look quite right. This is usually a sign that I am missing something obvious. Here is what I see. build_hash_table uses qsort to order targets in ascending order of //tag,index// into the array of checksums. It then accesses the targets in ascending order and writes the index at the tag's location in

I have been following this thread. I am working on rsync for an embedded application, but it has nothing to do with program loading. Donovan recently provided some formulas on figuring out the required checksum size relative to file size and acceptable failure rate. In the formulas, he assumes that the block size is square root of file size. I have done some benchmarking of rsync and for

I am trying to execute rsync manually at a "remote" server to test out --read-batch execution. I created the batch files on another server and then rcp'ed them to the "remote" server. I had some issues of not having the correct working directory on the remote system when I did an rsh "remote" rsync --read-batch ...... so I opened a telnet session on the remote

I am doing some benchmarking of rsync. I am using the --bwlimit= option to throttle down rsync to predict its operation over slow communications links. I am using rsync 2.6.2 from the release site without any patches. I downloaded the release rather than pull from the CVS tree. I have 2 servers "wilber" (the remote archive) and "judy" (the local archive) connected with a gig

When I dont specify --block-size but have --write-batch=xxx, I get a xxx.rsync_csum file that is 76 Kbytes in size. The size of the file varies as the size of the "reference" file is varied. --stats showed matched data that is roughly 6 block lengths based on the square root of the newer file. I copy the original data back to the target directory so that I can repeat the experiment. I

problem with --backup I am doing this the old fashioned way via e-mail. I deal with Bugzilla too much and would prefer to not open yet another bugzilla account that generates more e-mail that I dont need to sift through, especially when it looks very similar to in-house bugzilla stuff. I am running rsync 2.6.2 as it is downloaded with only the --bwlimit patch supplied by Wayne via e-mail

I have a 29 Gig full backup on a remote server (lets call if fedor) that is called Kbup_1. I have a 1.3 Gig incremental backup on my local server. I have rsync 2.6.2 on both servers. Both are RedHat Linux 9.1 on i-686 hardware platforms. I issue the command "time rsync -avv --rsh=rsh --stats /test/Kibbutz/Kbup_1 fedor://test/Kibbutz". The synch takes ~5 minutes of real time and about

Wayne replied to my original note which said that in a special situation that I was using to probe rsync to build a behavioral model that bwlimit= resulted in bimodal behavior around a 4000 kbyte/sec value. He responded with a patch that I have tested in a limited way. I have a push scenario from a local site to a remote site. I use a file that is 6.3 Megabyte in size whose checksums (when

I am seeing some rather strange behavior with synch of 2 directories on the same system using 2.6.2. The older file is the image of a full backup and is 29Gig in size. The new image is a slice of an incremental backup and is 101Meg in size. the command line is: time /home/wally/rsync/rsync-2.6.2 -av --rsh=rsh --backup --stats --block-size=<xxx> --write-batch=kbup1aaa