rsync - Aug 2002 - Is there anyway to fix large file support?

I got Large files working fine on Solaris, just make a 64bit binary :).
Seriously, I would try making a 64bit binary for HPUX as well(something
like +DA2.0W for 64bit PA_RISC).  

						Robert Weber
						University of Colorado
--------
> 
> I am currently writing disaster recovery software for the company I work 
> for.  I have been watching rsync development now for the past couple of 
> months, hoping that large file support would start working.  I know that 
> rsync supports large file support, and my tests have been with large file 
> support turned on in rsync.
> 
> It would save me MASSIVE amounts of time if I could use rsync for disaster 
> recovery, but we have about 10 files that are over 2 gigs in size.  That 
> all fail during transfer in rsync.
> 
> Please, help me! :)  I am using HP/UX 11.0.  I have also heard on this 
> lists from a few people running Solaris who cant get large file support to 
> work as well.
> 
> I am running todays cvs copy during this test.  It also fails in version 
> 2.5.5..
> 
> 
> My rsync:
> 
> rsync  version 2.5.6cvs  protocol version 26
> Copyright (C) 1996-2002 by Andrew Tridgell and others
> <http://rsync.samba.org/>
> Capabilities: 64-bit files, socketpairs, hard links, symlinks, batchfiles,
>               no IPv6, 32-bit system inums, 64-bit internal inums
> 
> 
> The error:
> 
> A failed large file over 2 gigs:
> 
> aurora:/premdordev/MP5.BCV # rsync --progress -arvvz SM.ORDERS 
> n4000.premdor.com:/premdor/SM.ORDERS
> opening connection using remsh n4000.premdor.com rsync --server 
> -vvlogDtprz . /premdor/SM.ORDERS
> building file list ...
> expand file_list to 4000 bytes, did move
> 1 file to consider
> delta transmission enabled
> SM.ORDERS
> rsync: writefd_unbuffered failed to write 16385 bytes: phase
"unknown":
> Broken pipe
> rsync error: error in rsync protocol data stream (code 12) at io.c(515)
> 
> 
> I can send hundreds of thousands of small files with no errors, it's
only
> the large files >2 gig that blow up.
> 
> My systems are at your disposal if you need my help doing anything.  I 
> just hope we can get this working.
> 
> Aharon
> 
> -- 
> Sr Unix Administrator
> Masonite International
> Tampa, Florida
> 
> Websites:
> http://www.tamparacing.com
> http://www.tampaforums.com
> http://www.ls6.com
> http://www.lastgen.com
> http://www.xmbforum.com
> 
> -- 
> To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/rsy
nc
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
--------

----------
Status: by weberr Wed Aug  7 15:28:13 2002
----------

Try the following:

$ rsh n4000.premdor.com uname -a

Check to see if the remote size shows file(blocks) is >2GB

$ dd if=/dev/zero bs=1048576 count=2560 | rsh n4000.premdor.com dd
of=/premdor/gigo.test

This should create a 2.5GB file on the far end.

As a security note, you might look into ssh for tighter security after you
get large files working. You can look at http://www.openssh.org/ for
starters.

Another thought would be to verify large files is enabled on the remote
file system. For example, on Solaris using ufs you can type in mount and
see the following:

$ mount
/export/home_new on /dev/md/dsk/d60
read/write/setuid/intr/largefiles/onerror=panic/dev=154003c on Tue Jul  2
10:03:59 2002

largefiles is in the fourth section. For a vxfs file system under Solaris,
you can also run:

$ /usr/lib/fs/vxfs/fsadm /export/home
nolargefiles

which shows that large files is not enabled.

Same thing applies to AIX. Not sure how that applies to HP-UX 11.x.
Haven't support it. But the idea should be the same. The tests above
should work regardless of the UNIX flavor.