Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: SGI 2GByte TCP limit
Summary: SV, ugh.
Message-ID: <88909@sgi.sgi.com>
Date: 5 Mar 91 17:21:19 GMT
References: <9103042301.aa02195@WOLF.BRL.MIL>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 45

In article <9103042301.aa02195@WOLF.BRL.MIL>, mike@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@sgi.com