Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!decvax!eagle_snax!geoff
From: geoff@eagle_snax.UUCP ( R.H. coast near the top)
Newsgroups: comp.protocols.nfs
Subject: Re: Problems with PC-NFS
Message-ID: <444@eagle_snax.UUCP>
Date: 16 Jan 89 13:51:44 GMT
References: <3650@phri.UUCP>
Reply-To: geoff@eagle_snax.UUCP (Geoff Arnold @ Sun ECD - R.H. coast near the top)
Organization: Sun Microsystems - East Coast Division
Lines: 76

In article <3650@phri.UUCP> roy@phri.UUCP (Roy Smith) writes:
>
>	We've recently gotten PC-NFS runnng on a PC-AT and have noticed a
>couple of problems.  One is that when I run NFSRUN, when it gets up to the
>"NET START RDR", it hangs for a few seconds and then I get:
>
>	Cannot send broadcast packet: unknown error
>	NFS028W: unable to find a YP server for domain PHRI
>	net: unable to get hostname by IP addr (128.122.136.101)
>
I assume you're using subnets and broadcasting for a YP server
(NET YPSET *), Roy. There is a bug in PC-NFS 3.0 which screws up
YP broadcasts in a subnetted network ("inet_netof" was inadvertantly
left typed "int" instead of "unsigned long"). It's fixed in the
next release: the workaround is to set the YP server explicitly. I'm
not sure why everything works after the glitch....

>	The second problem is that I can't seem to reliably talk to my Mt
>Xinu 4.3BSD/NFS Vax using NFS.  I can mount a file system from the vax and
>access it doing simple things (i.e. I can cd to it, do ls and cat, and copy
>small files from the PC to the vax) but if I try to write a large (i.e.
>Mbyte) file it eventually hangs.  I've never seen any problems with file
>systems mounted from a Sun (SunOS-3.5.2) server.  The only thing I can
>think of is that the vax has a problem with dealing with large block sizes.
>All our suns mount the vax file systems with (rsize=2048,wsize=2048).  Is
>it possible that I'm seeing the same problem with PC-NFS?  Is there any way
>to change the block size PC-NFS uses?  Somehow, the idea of a PC sending
>data too fast for a vax doesn't sound right, but that's all I can think of.

This comes up occasionally. I thought that Mt.Xinu had fixed it long ago,
but in any case there may be other implementations with this bug. The
problem is that certain people ported the Sun NFS code a little too casually,
without delving into the machine dependent issues. In the original
nfs/nfs_subr.c file you'll find this little procedure:

/*
 * Returns the prefered transfer size in bytes based on
 * what network interfaces are available.
 */
nfstsize()
{
        register struct ifnet *ifp;

        for (ifp = ifnet; ifp; ifp = ifp->if_next) {
                if (ifp->if_name[0] == 'e' && ifp->if_name[1] == 'c') {
                        return (ECTSIZE);
                }
        }
        return (IETSIZE);
}

In nfs/nfs.h, ECTSIZE and IETSIZE are defined:

/*
 * maximum transfer size for different interfaces
 */
#define ECTSIZE 4096
#define IETSIZE 8192

Now of course all of this is strictly machine dependent, but anyone
who didn't bother to check this will wind up with an NFS server that will
advertise a TSIZE of 8192 unless the interface name begins "ec". Back
at the first couple of Connectathons we ran into a number of implementations
which were using third-party TCP/IP packages that couldn't handle 8K
UDP datagrams, and of course the combination failed. Fortunately the
fix was easy.

There's no PC-NFS equivalent to WSIZE and TSIZE on mounts - any value
you patched would be overwritten by the TSIZE obtained from the 
server. The best solution is to adb your Vax kernel and check out
the nfstsize() code, patching it if necessary.
-- 
Geoff Arnold, Sun Microsystems Inc.  | "It is well known that the longer one
PC Dist. Sys. Group (home of PC-NFS) |postpones a pleasure, the greater the
UUCP: {hplabs,decwrl...}!sun!garnold |pleasure when it arrives. Therefore, if
ARPA: garnold@sun.com                |one postpones it forever..." (Smullyan)