Lots of NFS cross mounts?

[Michael Meissner]

In article <106600042 at datacube> berger at datacube.UUCP writes:
| 
| We are planning to have about 30 Sun 3/50's and 3/60's on our network.
| Our plan is to put 150Mbyte to 380Mbyte SCSI drives on all of these
| instead of running them diskless. It seems to be cheaper than having a
| few large nd servers. Personal and some group file systems would be on
| each of these local disks and they would generally be cross NFS
| mounted all around the net.
| 
| Does anyone have any experience with having many (30 or more) partions
| cross mounted on many (30 or more) machines? Are there any impacts
| that we should be aware of?
| 
| One thing that makes us nerveous is a problem we have seen on our
| current set up. The problem is when one server is down but clients
| have partitions of the downed server NFS mounted.  The clients get
| bogged down even when they are not explicitly trying to access
| partitions on the downed server. We are using Soft mounts.... 

I do not have direct experience with NFS on Suns, but I do have some with
Data General's port of NFS on it's native unix (DG/UX).  However, since
the majority of UNIX's seem to implement file lookup in the same way, it
should apply to other machines.

When you are scanning a directory (readdir, getdirent) and running stat
and hit an entry that is a NFS mounted disk, you will either time out
(soft mount) or wait until the server comes up (hard mount).  In the
classical UNIX implementation, the order searched by readdir is in
directory slot order (ie, in a new directory . and .. fill the first two
slots, the next entry created gets the next free slot.  Deleting entries
puts the slots on the free list and so forth.  Thus if you are searching
for an entry "fred", but "barney" is in a previous slot and is currently
down, you will be pended.  Thus for frequently searched file systems (/,
/usr in particular), you can put local files and directories ahead of
remote directories, by careful moves, renames, deletions.  For systems
that use hashing, you probably don't have that option, and have to hope
for the best.

You may be saying that acceptable for when you have to search the entire
directory for things like ls, and it typically is.  However, the usual
implementation of pwd is to open the parent directory, do readdir until
it finds an entry whose inode corresponds to ".".  This is repeated for
succesive parent directories until you come to "/".  It turns out that
lots of commands do a pwd (or popen("pwd"), getcwd, or getwd which
amount to the same thing).
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner
					Arpa/Csnet:  meissner at dg-rtp.DG.COM