SGI 2GByte TCP limit

[Mike Muuss]

Over the past few weeks, we have encountered difficulty using RDUMP
on an SGI 280 server.  We are attempting to dump a 4 Gbyte (4-way
stripe) filesystem across the network to a Gould running BSD UNIX.
(The motivation for this is, alas, that our SGI-provided tape
drives have been having a rough time of it lately.)

We have been most disturbed by the fact that the RDUMP aborts on the
15th reel (!), repeatably.  150 Mbytes/reel * 15 reels = 2.1 Gbytes.
2 Gbytes = 2**31.  Suspicious!

Chuck Kennedy ran some tests for me using (the BRL-original version) of
TTCP, and encountered the same difficulty.  Running from SGI to SGI
(IRIX Release 3.3.1), the sys-write() call returns an error 27
after about 1 hour and 47 minutes of data transfer.  (Alas, we don't
know the exact byte count at this point).
	
	#define        EFBIG   27      /* File too large */

Amusingly, both the sender and receiver got this error 

While this was the first time that I can recall having intentionally
transferred 2 Gbytes of data on a TCP connection, it seems like an
unfortunate limitation.

Just as a sanity check, Chuck also ran the same test between two
Gould PN 9080 systems (running UTX 2.0, a 4.3 BSD system).
The test was to send 3000 buffers of 1048576 bytes each, or about
3 Gbytes.  The Goulds successfully transmitted the entire sequence,
without error.

So, my questions to SGI are:

*)  Is this limit intentional?
	*)  If yes, why?
	*)  If no, when will it be fixed?

*)  Is there an easy work-around, like a periodic lseek(fd,0L,0) ?

	Best,
	 -Mike

PS:  SGI folks, please don't get paranoid about my finding all these
little problems with SGI machines.  It's a function of my getting a lot
of work done on them.