From: brendan@microunity.com (Brendan Eich)
Subject: Re: nfs loopback mounts
Summary: Loopback kernel-to-user works; kernel-to-kernel doesn't
Organization: MicroUnity Systems Engineering, Inc.
Date: Fri, 16 Oct 1992 00:05:22 GMT

In article <1992Oct15.214820.27417@mintaka.lcs.mit.edu> james@brokaw.lcs.mit.edu (James W. O'Toole Jr.) writes:
>We are having trouble doing loopback mounts via NFS on our SGI
>file server.  We have a user-level file server which provides content-based
>access to our Unix file system.  It works just fine on our Vax running
>Berkeley Unix.  We normally keep it mounted in about the same way that
>automount servers (such as amd or automount) are mounted.  We run the
>mount command and specify the port number on which the user-level process
>is ready for nfs traffic.

First it should be noted that amd and automount work on SGIs.  So do the
mount_iso9660 and mount_dos user-level loopback NFS servers.  So what you
are trying to do can be done.  I've written several user-level loopback NFS 
servers, including the NFS part of mount_dos (mount_dos and mount_iso9660
hide behind mount(1M) -- see fstab(4) for type-specific descriptions).

>On our SGI machine under OS versions 4.0.1 and 4.0.5 (which we just installed),
>we are unable to perform the mount command.  The command hangs and later most
>direct access to the sgi file system (not via nfs) blocks, and we have to
>reboot the machine.

It's likely the server is not answering requests.  'netstat -I lo0' would
help to confirm that packets are being sent; 'nfsstat -cn' would show NFS
packets were sent on some interface; if you run these on an otherwise quiet
system you should be able to verify that mount is attempting to speak NFS
to your loopback port.  If you happen to have NetVisualyzer,

  netsnoop -vvi lo0 -p udp.setport=<your-port>/sunrpc udp.port <your-port>

will capture UDP traffic involving your port, and decode it as NFS.

'netstat -a | grep "^udp.*<your-port>"' would confirm that packets got into
your user-level NFS server's UDP socket, but have not yet been received.

>We don't think our user-level server is ever getting any nfs traffic, and,
>in fact, just doing this test on "localmachine":
>
>   /etc/mount -o soft,intr useless:/usr /mnt
>

(I assume "useless" is the "localmachine".)  One NFS no-no committed here
is the use of a root-level mount point, /mnt.  If anything goes wrong with
the server or the connection to it, not only will processes doing NFS over
this connection hang, but unrelated processes dealing with local files may
hang, because of the way pwd/getwd works (search each directory along the
ancestor line and lstat entries until you find one with a dev/ino matching
the last ancestor directory).

You should mount on /tmp/mnt or /n/mnt or something "away from /".  This
standard NFS folk-practice has evolved without clear documentation to help
promulgate it, with only bitter experience.

>which doesn't involve our server, produces the same hanging/blocking problems.
>We expect this command to mount the local machine's /usr loopback on /mnt.
>Substituting "localhost" for "useless" doesn't change the results.

Unfortunately, you are testing something different: whether kernel client
to kernel server loopback NFS operations work.  Kernel client to user-level
server loopback NFS works fine (amd, automount, mount_dos, etc.).  Kernel
to kernel does not, for a couple of reasons; I consider this a bug, but it
is not very high priority.  And it is not relevant to the difficulties with
your user-level NFS server.

>We've already discussed this with SGI Customer Support.  Apparently SGI
>considers loopback mounts to be a special case of nfs which is not supported
>by their implementation.  However, we've been informed that loopback mounts
>do work on our customer support engineer's machine.  But loopback mounting
>isn't officially supported "because customers may experience problems when
>using loopback mounts."

They should say "Irix does not support kernel client to kernel server
loopback NFS."

>Can anyone shed some light on this problem?  What possible problem is there
>with loopback mounts?

Kernel-to-kernel loopback NFS may hang because of deadlocks between client
and server processes that share kernel resources (looped-back mbufs that
contain NFS requests and responces, filesystem buffers, etc.).  Prior to the
advent of multiprocessor Irix, kernel/kernel NFS loopback worked reliably.
This may have been luck rather than design, as uniprocessor Irix was not
then, as MP Irix is not now, anything like SunOS.  There is a low priority
bug on file against NFS for not supported kernel/kernel loopback mounts, I
believe.  It may be closed some day, but until then user-level loopback NFS
servers should work fine.

>Since loopback mounts work some of the time, what is
>known about when the SGI implementation will accept a loopback mount and when
>it will reject it?

Kernel-client/kernel-server loopback hangs; kernel/user works.

>What is the special sgi_mountd RPC program, and does it
>have anything to do with this problem?

This is an extended RPC protocol that supports full (string) exportfs(1M)
option enquiry in addition to the usual MOUNTPROG remote procedures.  It's
not relevant to loopback difficulties.

With a quiet system, a good debugger, netstat, and nfsstat, you should be
able to find the problem -- let me know if you find something other than a
bug in the user-level NFS server or its configuration.

/be
-- 
-----
Brendan Eich
MicroUnity Systems Engineering, Inc.
brendan@microunity.com
Newsgroups: comp.sys.sgi