Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!vjs@rhyolite.wpd.sgi.com
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.protocols.nfs
Subject: Re: Forcing a umount
Keywords: nfs, umount, mount, fuser
Message-ID: <93840@sgi.sgi.com>
Date: 27 Mar 91 02:58:22 GMT
References: <118@gordius.gordian.com> <93325@sgi.sgi.com> <10472@exodus.Eng.Sun.COM>
Sender: guest@sgi.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 58

In article <10472@exodus.Eng.Sun.COM>, brent@terra.Eng.Sun.COM (Brent Callaghan) writes:
(in response to an off hand complaint of mine about automounter hangs)
> ...
> BTW: it's not easy to hang the automounter with a dead NFS mount.

some agreement, but see below.

>                                     A multithreaded automounter will
> definitely be an improvement.

Much agreement, providing the locking hassles are safely resolved.
One would not want new problems in the style of the lock-demons.

Real life example from the campus of a workstation maker on the non-solar
side of the Mtn.View dump: 

    Consider a bunch of source machines, all mounted indirectly in /net, via
    some handy map.  Imagine `ln -s /net/{foo,bar,new,dead,so_on} /` so that
    symbolic links within the trees source work universally.  (Some people
    mount on /n, some in /hosts, and the symbolic links must work on the
    servers as well.)

    Now imagine what happens if 
      (1) you have foo,bar, and new all properly mounted, 'dead' not
	   mounted, and the server for dead dies or becomes unreachable
      (2) vi /dead/src/whatever.c
	   which is sym-link resolved into /net/dead/src/whatever.c
      (3) long pause
	    grumble
	    realize the trouble
	    do something about the network or the server for dead
      (4) try to do something useful while the 10GB of file systems for
	      'dead' are fsck'ing
	  so `vi /foo/src/stuff.c`

    Now you've hung another window, as namei() tries to resolve the
    /foo->/net/foo link by talking to the file system mounted on /net.
    Until the automounter stop patently waiting for the server for dead to
    answer the mount protocol or for a timeout, you're stuck.

There is no equivalent hiccup in the obvious manual NFS mounting of
{foo,bar,...} on /net.


An obvious solution is to have the automounter not do the unmount when it
times out.  Instead, let the automounter locally unmount the filesystem,
but cache the fh etc. and not bother to tell the server.  Later when the
file system is referenced, the automounter should first consult its cache
of file handles etc, and do only the local part of the (re-)mount.  Yes, it
would need a varient mount system call.

There are few good reasons to tell server when the automounter hits the
default 5 minute timeout.  It justs wastes server cycles and network
bandwidth to update /etc/rmtab.  For many years B.Lyon has been saying
/etc/rmtab is a botch that should be deleted.


Vernon Schryver,   vjs@sgi.com