Bug 1457 - writefd_unbuffered failed to write
writefd_unbuffered failed to write
Status: CLOSED INVALID
Product: rsync
Classification: Unclassified
Component: core
2.6.2
x86 All
: P3 critical
: ---
Assigned To: Wayne Davison
Rsync QA Contact
:
Depends on:
Blocks: 1477
  Show dependency treegraph
 
Reported: 2004-06-13 09:28 UTC by Mark Fonnemann
Modified: 2004-06-24 06:42 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Fonnemann 2004-06-13 09:28:32 UTC
the zip drive is a firewire iomega 750mb drive... the folder /home/zip750
contains roughly 350MB.

[root@markf78 zip750]# rsync -vr /home/zip750 /mnt/zip/zip750
building file list ... done
zip750/#canadienkings.txt#
zip750/C/2b.c
zip750/C/fileio.h
zip750/C/hash.c
zip750/C/hash.h
zip750/C/httpfn.c
zip750/C/httpfn.h
zip750/C/random.c
zip750/C/random.h
zip750/C/stringfn.c
zip750/C/stringfn.h
zip750/C/tcpsocket.c
zip750/C/tcpsocket.h
zip750/JPEGs/Diploma.jpg

(snip)

zip750/backups/Linux/Xmms/xmms-1.2.10-1.i386.rpm
zip750/backups/Linux/Xmms/xmms-alsa-1.2.10-1.i386.rpm
zip750/backups/Linux/dd_rescue-1.03.tar.gz
zip750/backups/Linux/ghex-2.4.0.1-0.fdr.4.1.i386.rpm
zip750/backups/Linux/kernel-2.6.3-2.1.253.2.1.i686.rpm
zip750/backups/Linux/modprobe.conf

mkstemp "/mnt/zip/zip750/zip750/C/.2b.c.v2TNLo" failed: No such file or
directory

zip750/backups/Macintosh/.DS_Store
zip750/backups/Macintosh/Connectix Virtual PC 6.0.sit
zip750/backups/Macintosh/RealOnePlayerGold.sit
zip750/backups/Macintosh/serial number.rtf
zip750/backups/Windows/AdbeRdr60_enu_full.exe
zip750/backups/Windows/Dell BIOS vA10.exe.gz
zip750/backups/Windows/DirectX 8.1.exe
zip750/backups/Windows/GoogleToolbarInstaller.exe
zip750/backups/Windows/MPEG-4 v1.1.exe
zip750/backups/Windows/QuickTime 6.4.exe
zip750/backups/Windows/Windows Media Player v9 Runtime.exe
zip750/backups/Windows/ie4.zip

rsync: writefd_unbuffered failed to write 4 bytes: phase "unknown":
Broken pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(836)
rsync: writefd_unbuffered failed to write 69 bytes: phase "unknown":
Broken
pipersync error: error in rsync protocol data stream (code 12) at
io.c(836)

i can duplicate it every time...

[root@markf78 zip750]# rpm -q rsync
rsync-2.6.2-0

i originally thought this was a Fedora Core bug but apparently it has been
duplicated on AIX.
Comment 1 Michael Wang 2004-06-13 12:05:48 UTC
The same problem is duplicated on AIX 5.2 with current patch level 02.

It appears that the problem occurs for large files. In the test shown below,
it is 4.6GB. 

This happens for rsync 2.5.4 using the IBM build:
http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html

This also happens for current rsync version 2.6.2 built using gcc 2.9
(The gcc is built by IBM available from same URL as above). The error with
rsync 2.6.2 is shown below.

$ ls -l
-rw-r--r--   1 oracle   oinstall 4666171392 Jun 11 23:30 maxdataMXPDB02.dbf

$ rsync -av maxdataMXPDB02.dbf /net02/oracle/

building file list ... done
maxdataMXPDB02.dbf

rsync: writefd_unbuffered failed to write 32768 bytes: phase "unknown":
Broken pipe
rsync error: error in rsync protocol data stream (code 12) at io.c(836)
Comment 2 Michael Wang 2004-06-13 12:32:40 UTC
The problem occurs when both the source and destionation are locally mounted 
file systems. In the words, the problem is not related with network at all.

As a matter of fact, I actually successfully transferred a > 6GB file over the 
network to a Solaris 8 box from AIX 5.2.

So this seems to indicate network is ok, local has the problem.
Comment 3 Wayne Davison 2004-06-14 07:30:25 UTC
Did you investigate why the temp file could not be created?

/mnt/zip/zip750/zip750/C/.2b.c.v2TNLo

I would imagine that the zip disk is either full or that its file system doesn't
support large files.  Remember that you must have enough free space to store an
extra copy of the largest transferred file that is being updated (or you must
use the --temp-dir option to force the temp file onto another disk).
Comment 4 Mark Fonnemann 2004-06-14 09:24:35 UTC
using the switch --temp-dir solves my problem.. sorry for the incovenience. thanks.
Comment 5 Wayne Davison 2004-06-14 10:04:08 UTC
Looks like a zip-disk overflow -- closing.