Hello,
(Sorry, my english is no good)
I've been searching for solutions but I don't find it.
I'm using last version of cygwin (1.5.25-15) on Windows 2003 Server for
transfer a Virtual Machine Backup (<2 GB .vmdk files; VCBMOUNTER) to a
remote site with same rsync version.
Sometimes this rsync task fails to transfer a file with compress (z) but
doesn't fail without this argument. My frame of time for transfers is
reduced and, at this moment, I'd need compress.
Anybody knows why or how to solve it? Is compress the random problem? Could
be a programming bug?
This error happen with compress but not always.
Where can I find values for --compress-level parameter?
I hope to have explained it.
Thanks in advance, Miguel.
LOGS:
The command line is:
rsync -avvzPhh --inplace local_file remote_dir
and the result is an error.
1.- ERROR
*-vvz OUTPUT over LAN
2008/12/05 14:02:25 [4012] opening tcp connection to 192.168.1.50 port 873
2008/12/05 14:02:25 [4012] building file list
2008/12/05 14:03:23 [4012] rsync: writefd_unbuffered failed to write 4 bytes
[sender]: Software caused connection abort (113)
2008/12/05 14:03:23 [4012] rsync: read error: Software caused connection
abort (113)
2008/12/05 14:03:23 [4012] rsync error: error in rsync protocol data stream
(code 12) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c(791)
[sender=3.0.4]
*
2.- ERROR
*-vvz OUTPUT over WAN* (dedicated line 2Mbps)
*2008/12/03 21:40:31 [988] opening tcp connection to 10.13.25.154 port 873
2008/12/03 21:40:31 [988] building file list
2008/12/03 21:41:15 [988] rsync: writefd_unbuffered failed to write 4 bytes
[sender]: Connection reset by peer (104)
2008/12/03 21:41:15 [988] rsync: read error: Connection reset by peer (104)
2008/12/03 21:41:15 [988] rsync error: error in rsync protocol data stream
(code 12) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c(791)
[sender=3.0.4]
*
3.- ERROR
*-vvvz OUTPUT over LAN
2008/12/05 15:27:52 [3828] opening tcp connection to 192.168.1.50 port 873
2008/12/05 15:27:52 [3828] building file list
2008/12/05 15:27:52 [3828] [sender]
make_file(scsi0-2-0-CARTA_1-s002.vmdk,*,0)
2008/12/05 15:27:52 [3828] send_file_list done
2008/12/05 15:27:52 [3828] send_files starting
2008/12/05 15:27:53 [3828] send_files(1,
/cygdrive/C/VCB/KARTA/scsi0-2-0-CARTA_1-s002.vmdk)
2008/12/05 15:28:48 [3828] send_files mapped
/cygdrive/C/VCB/KARTA/scsi0-2-0-CARTA_1-s002.vmdk of size 1076953088
2008/12/05 15:28:48 [3828] calling match_sums
/cygdrive/C/VCB/KARTA/scsi0-2-0-CARTA_1-s002.vmdk
2008/12/05 15:28:48 [3828] built hash table
2008/12/05 15:28:48 [3828] hash search b=32816 len=1076953088
2008/12/05 15:28:48 [3828] match at 0 last_match=0 j=0 len=32816 n=0
2008/12/05 15:28:48 [3828] match at 32816 last_match=32816 j=1 len=32816 n=0
...
2008/12/05 15:28:53 [3828] match at 56902944 last_match=56902944 j=1734
len=32816 n=0
2008/12/05 15:28:53 [3828] match at 57001392 last_match=56968528 j=1737
len=32816 n=32864
2008/12/05 15:28:53 [3828] rsync: writefd_unbuffered failed to write 4092
bytes [sender]: Software caused connection abort (113)
2008/12/05 15:28:53 [3828] rsync: read error: Software caused connection
abort (113)
2008/12/05 15:28:53 [3828] rsync error: error in rsync protocol data stream
(code 12) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c(791)
[sender=3.0.4]
2008/12/05 15:28:53 [3828] _exit_cleanup(code=12,
file=/home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/io.c, line=791):
about to call exit(12)
*
4.- OK
-vv OUTPUT WITHOUT COMPRESS (z)
2008/12/05 13:57:15 [940] opening tcp connection to 192.168.1.50 port 873
2008/12/05 13:57:15 [940] building file list
2008/12/05 13:59:27 [940] <f..t...... scsi0-2-0-CARTA_1-s002.vmdk
2008/12/05 13:59:27 [940] total: matches=31167 hash_hits=21385725
false_alarms=442 data=54176816
2008/12/05 13:59:27 [940] rsync[940] (sender) heap statistics:
2008/12/05 13:59:27 [940] arena: 327680 (bytes from sbrk)
2008/12/05 13:59:27 [940] ordblks: 4 (chunks not in use)
2008/12/05 13:59:27 [940] smblks: 0
2008/12/05 13:59:27 [940] hblks: 0 (chunks from mmap)
2008/12/05 13:59:27 [940] hblkhd: 327680 (bytes from mmap)
2008/12/05 13:59:27 [940] allmem: 655360 (bytes from sbrk + mmap)
2008/12/05 13:59:27 [940] usmblks: 2686976
2008/12/05 13:59:27 [940] fsmblks: 0
2008/12/05 13:59:27 [940] uordblks: 479936 (bytes used)
2008/12/05 13:59:27 [940] fordblks: 175424 (bytes free)
2008/12/05 13:59:27 [940] keepcost: 44072 (bytes in releasable
chunk)
2008/12/05 13:59:27 [940] Number of files: 1
2008/12/05 13:59:27 [940] Number of files transferred: 1
2008/12/05 13:59:27 [940] Total file size: 1.00G bytes
2008/12/05 13:59:27 [940] Total transferred file size: 1.00G bytes
2008/12/05 13:59:27 [940] Literal data: 51.67M bytes
2008/12/05 13:59:27 [940] Matched data: 975.40M bytes
2008/12/05 13:59:27 [940] File list size: 70
2008/12/05 13:59:27 [940] File list generation time: 0.001 seconds
2008/12/05 13:59:27 [940] File list transfer time: 0.000 seconds
2008/12/05 13:59:27 [940] Total bytes sent: 51.79M
2008/12/05 13:59:27 [940] Total bytes received: 224.37K
2008/12/05 13:59:27 [940] sent 51.79M bytes received 224.37K bytes 401.96K
bytes/sec
2008/12/05 13:59:27 [940] total size is 1.00G speedup is 19.75
-------------- next part --------------
HTML attachment scrubbed and removed
Matthias Meyer
2008-Dec-05 17:42 UTC
ERROR: writefd_unbuffered failed to write ... when COMPRESS
Am Freitag 05 Dezember 2008 schrieb MATV:> Hello, > (Sorry, my english is no good) > > I've been searching for solutions but I don't find it. > > I'm using last version of cygwin (1.5.25-15) on Windows 2003 Server for > transfer a Virtual Machine Backup (<2 GB .vmdk files; VCBMOUNTER) to a > remote site with same rsync version. > > Sometimes this rsync task fails to transfer a file with compress (z) but > doesn't fail without this argument. My frame of time for transfers is > reduced and, at this moment, I'd need compress. > Anybody knows why or how to solve it? Is compress the random problem?Could> be a programming bug? > This error happen with compress but not always. > > Where can I find values for --compress-level parameter? > > I hope to have explained it. > > Thanks in advance, Miguel. >I've this feature too. In my experience you have no chance. -c did not work on windows clients. But you can try a ssh-tunnel and let ssh do the compression job. br Matthias -- Don't Panic