SGI 2GByte TCP limit

[Vernon Schryver]

In article <9103042301.aa02195 at WOLF.BRL.MIL>, mike at BRL.MIL (Mike Muuss) writes:
>                                      ....   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 */
> 
>  ...
> So, my questions to SGI are:
> 
> *)  Is this limit intentional?
> 	*)  If yes, why?

Be nice.
The 2/4GB SystemV limit has been a matter of internal controversy for a
years.  No one who has proposed a solution has argued with any conviction.

> 	*)  If no, when will it be fixed?

RealSoonNow.  If we're lucky in figuring out a clean fix, and in navigating
the shoals of release cycles, in the NextMajorRelease.

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

The offending, largely standard SVR3 code is in rdwr() is:
        if (fp->f_offset < 0) {
                u.u_error = EFBIG;
and later
        if ((type != IFCHR) || (cdevsw[major(ip->i_rdev)].d_str == NULL))
                fp->f_offset += uap->count - u.u_count;

My obviously false recollection is that we faked sockets as IFCHR devices
under the FSS years ago when we stuck 4.3BSD TCP into 3.4.  Oh, well.

With `dbx -k /unix /dev/kmem` you could patch the the first test in a
running system.  (Look near line 110 in file sys2.c.  Dbx knows line
numbers even if you do not have source.)  It's too bad we don't have an
equivalent of `adb -w...`.  If you can change RDUMP to use send() instead
of write(), it seems likely that the problem would go away there.  I doubt
an lseek() would help because of the following in seek():
	if ((ip->i_ftype == IFIFO) || (ip->i_ftype == IFSOCK)) {
		u.u_error = ESPIPE;


Vernon Schryver,   vjs at sgi.com