Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.nfs
Subject: Re: perculiar NFS behaviour
Message-ID: <1991Apr17.234557.26423@Think.COM>
Date: 17 Apr 91 23:45:57 GMT
References: <1991Apr15.045511.6354@massey.ac.nz> <130@gordius.gordian.com> <11700@exodus.Eng.Sun.COM>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 30

In article <11700@exodus.Eng.Sun.COM> brent@terra.Eng.Sun.COM (Brent Callaghan) writes:
>In article <130@gordius.gordian.com>, johnk@gordian.com (John Kalucki) writes:
>> ...but what I'd really like is some method to allow me to umount a
>> dead nfs filesystem.
>What's the problem ?  SunOS lets you unmount a dead NFS filesystem.

This is basically true, but circumstances often prevent it.  You identified
the problem with hierarchical mounts; a solution to this is to avoid
hierarchical mounts and use symbolic links to emulate them.

A worse problem is that you can't unmount a file system on which any
process has a file open.  You generally don't notice that a file server is
down until you start seeing "NFS server xxx not responding", and these
occur when someone is trying to access a file on that file system.  Unless
you have the file system mounted soft, the process won't continue until the
file server comes back.  This causes a deadlock: the process can't close
files because the server is down, and the file system can't be unmounted
because the process hasn't closed all its files.

Another deadlock occurs if the file system configuration on the server
changes in such a way that old handles to the root of the file system
becomes invalid (I think this can sometimes happen as a result of the fsck
that runs when the server reboots, if the file system needed lots of
fixing).  Unmount gets a "stale file handle" error when it tries to
reference the mount point, and it can't unmount it.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar