Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!sgi!vjs
From: vjs@rhyolite.SGI.COM (Vernon Schryver)
Newsgroups: comp.sys.sgi
Subject: Re: NFS problems and RE:RE:VT100/Keyboard
Message-ID: <7890@sgi.SGI.COM>
Date: Wed, 11-Nov-87 13:25:28 EST
Article-I.D.: sgi.7890
Posted: Wed Nov 11 13:25:28 1987
Date-Received: Sat, 14-Nov-87 02:28:51 EST
References: <8711042328.aa12082@SMOKE.BRL.ARPA> <2868@batcomputer.tn.cornell.edu>
Sender: daemon@sgi.SGI.COM
Organization: Silicon Graphics Inc, Mountain View, CA
Lines: 46
Summary: NFS does so work

In article <2868@batcomputer.tn.cornell.edu>, sparks@batcomputer.tn.cornell.edu (Steve Gaarder) writes:
>             We have the following trouble:
> 1. "pwd" does not work in most (but not all) NFS directories.  It gives
>    "read error in .."
> 2. C-shell scripts do not work in the same directories.  The error here is
> "file not found".  Bourne shell scripts run fine.
Well,  nobody's perfect... :-)

The infamous "can't pwd" problem and, I think the csh problem, is a
difficulty with System V file directories.  Your server probably has a
large file system with >64K inodes.  Standard SV gives i-numbers 16 bits
in many places, including stat.h.  That makes things like ftw(3), pwd(1),
and so on unhappy when they try to stat(2) a file descriptor, and then
use readdir/getdents to find its name.  (Yes, pwd(1) does something else,
but the problem is the same.)  In the latest version of EFS for the IRIS 4D,
we changed to 32-bit i-numbers and recompiled the world.  We could do that
since we had control of all 4D binaries and file systems in the world.

However, release 3.5 and 3.6 kernels were/will be binary compatible for
application programs.  This means we could not change ino_t in types.h
to a long (one of things done for the new EFS on the 4D).

Fortunately, there is a hack involving type punning in the user code that
makes csh, pwd, and other utilities work 99.999999% of the time (Yes, 
that's what I calculate it to be :-).  3.6 will have the hack in all of
the places that matter.  Contact the hotline if you're application code
messes with i-numbers and you need the hack.  Try them if you need help
before you receive 3.6.

You might not need more than 64K inodes on your server file system.  A
300MB disk should have about 70K inodes, assuming 'typical' file sizes.
You might want to check 'df -i' or the ULTRIX equivalent to see if you
could rebuild it with <64K inodes.

> 3. Occasionally, if there are 2 or more users running ld, the server
> or one of the clients will crash.
If the Microvax, crashes, you should call the manufacturer.
If an IRIS crashes, call the hotline.  We can only fix the problems
the hotline tells us about or that we find ourselves.

Inside SGI we use NFS quite heavily for development.  The source servers
tend to be 4D's with Eagles with 80K inodes.  Most of the hundreds of
clients are 3000's, but there are plenty of 4D's and others.  I daily use
two 3030's and four 4D's as clients and servers for kernel and user-code
builds and debugging--all linked with NFS.  The news article to which
I'm responding is NFS mounted on my personal 3030.