Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uwm.edu!lll-winken!sun-barr!newstop!male!jethro!exodus!terra.Eng.Sun.COM!brent
From: brent@terra.Eng.Sun.COM (Brent Callaghan)
Newsgroups: comp.protocols.nfs
Subject: Re: Forcing a umount
Keywords: nfs, umount, mount, fuser
Message-ID: <10472@exodus.Eng.Sun.COM>
Date: 26 Mar 91 07:44:03 GMT
References: <118@gordius.gordian.com> <93325@sgi.sgi.com>
Sender: news@exodus.Eng.Sun.COM
Lines: 70

In article <93325@sgi.sgi.com>, vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> In article <118@gordius.gordian.com>, johnk@gordian.com (John Kalucki) writes:
> > 
> > I'm having trouble arranging my nfs links to avoid halting all of
> > my machines when one machine crashes....
> > When one machine goes down, all others have difficulties, ranging
> > from simply freezing up to having pwd(1) timeout....
> 
> 
> Symbolic links from /{mach} to /mount/point could make the /{mach}/{mach}
> mounting scheme palatable, since there are only 6 machines and 30-36
> links involved.  Things change when you go from dozens to grosses....pun
> possibly intended
> 
> The automounter sounds like a good bet for the situation described.  It's
> reduced many of the dead host problems around here, where everyone has from
> two to several dozen mounts, with many of the most used servers several
> buildings, routers, and networks distant.  The automounter helps, because
> you're more likely to get messed up only by the (network) crash of a
> machine you currently care about.
> 
> Unfortunately the single thread nature of the automounter makes things
> more painful when a server you care about does crash or become unreachable. 
> The Sun automounter is not too smart about doing other mounts while it is
> waiting to give up on a dead server.

The automounter can help reduce the incidence of NFS hangs through
a reduction in the number of static NFS mounts that getwd might
bump into, though I'd not recommend it as a solution to this problem.

Hangs due to dead servers are no surprise if the filesystem that
you're dealing with *directly* becomes temporarily unavailable due
to a server crash.  What annoys me (and other NFS users) is where
your application hangs due to a dead NFS filesystem that you have
no interest in.  There are two well-known mechanisms for this kind
of hang: You type a command and the $PATH search hangs on a dead
directory in the PATH.  A workaround here is to keep the PATH as
short as possible and substitute shell aliases where possible.
Another mechanism is the getwd() mechanism: this function does
a file tree walk in order to construct a path from the current
directory to the root.  If the walk (climb?) up the tree trips over
a dead NFS mountpoint then the process that invoked getwd() is hung.
This problem can be avoided by implementations that walk up to the
first mountpoint and prepend the remainder of the path from the
/etc/mtab entry.  If the /etc/mtab entries have the device id
stashed in the mount options (as a "dev" or "fsid" string) then
getwd shouldn't hang except if invoked withing a dead filesystem.

BTW: it's not easy to hang the automounter with a dead NFS mount.
After the automounter has done a mount, it doesn't give a brass
razzoo about whether the server is up or not.  It just points its
symbolic link at the mountpoint in /tmp_mnt and the application that
asked for it follows it. If the mountpoint is dead then the application
hangs, but the automounter carries on.  

In SunOS 4.0.3 the automounter could hang in unmount(2).  An unmount
of a dead NFS mountpoint will succeed - the kernel does not contact
the server when it does an unmount(), but if the path to the mountpoint
contains a dead server then it will hang in the lookup.  The 4.1
automounter carefully pings servers along the path before attempting
the unmount system call.  Of course, a lot of this jiggery-pokery
wouldn't be necessary if the automounter didn't have to be so paranoid
about it's single thread blocking.  A multithreaded automounter will
definitely be an improvement.

--

Made in New Zealand -->  Brent Callaghan  @ Sun Microsystems
			 Email: brent@Eng.Sun.COM
			 phone: (415) 336 1051