SCO NFS dies when heavily used

[Barnacle Wes]

In article <1991Jun06.171047.15327 at nss1.com>, mrm at nss1.simpact.com (Michael R. Miller) writes:
> The SCO OS/NFS is exporting its directory.  A SUN OS/NFS is importing
> the directory.  Large numbers of reads and writes are going back and
> forth for some time -- sometimes just a few minutes to an hour, other
> times a couple of days -- and then the software decides to lay over
> and play dead.  We need to reboot the machine to breath life into its
> networking support.
> 
> The SUN's NFS continues to operate although that window is "dead"
> with the program running in the window waiting for a never-to-be-answered
> NFS request.  We have determined that the SUN isn't at fault by successfully
> reading and writing another NFS mounted directory exported by another SUN.
> The SUN is an OS 4.1 product.

This doesn't necessarily mean that the Sun NFS is correct, or bug-free,
but just that Sun NFS has a bug-set that is compatible with (surprise!)
Sun NFS.  If you have another SCO system, try doing the same test with
an SCO client & server.  This may help to narrow the possibilities.

Also, when you encounter this problem, does the entire network on the
SCO box die, or just NFS?  In other words, do telnet, ping, finger, etc
still work?  If so, it may just be a problem with SCO-NFS.  If it
crashing the entire network, including inetd, the problem may be in
your TCP/IP software rather than the NFS server.  Does nfsstat show any
problems before or after the crash, such as lots of rpc badcalls?

Good luck bug-hunting.

	Wes Peters
-- 
#include <std/disclaimer.h>                               The worst day sailing
My opinions, your screen.                                   is much better than
Raxco had nothing to do with this!                        the best day at work.
     Wes Peters:  wes at harem.clydeunix.com   ...!sun!unislc!harem!wes