handling unresonsive NFS servers

[Rick Macklem]

I have been thinking about what to do on a client when an NFS server is
unresponsive and thought I'd email to see what others thought?

"intr mounts" - These don't work correctly and it is nearly impossible
 	to make them work correctly. The problem is that, often, the
 	process which has a termination signal posted against it is blocked
 	waiting for some resource (vnode lock, buffer cache block,...) that
 	another process that is waiting for an RPC reply from the
 	unresponsive server, holds. Also, for NFSv4, a client can't just
         forget about an RPC that alters state on the server. If it does
         so, the RPC may have been performed on the server and the client's
         view of state might become inconsistent with the server's view.
 	(As such, I feel this should be "deprecated or disabled". I don't
 	 like things that "sorta work", but I can understand why some might
 	 feel that it should remain for NFSv2,3.)

"soft mounts" - These have the problem that system calls may terminate
 	abnormally when all you have is a slow, heavily loaded server.
 	As such, they might be ok for read-only mounts using NFSv2,3,
 	but seem too dangerous for anything else. (Very few apps. expect
 	an I/O system call to fail with ETIMEDOUT.)

So, about all I can think to do is make "umount -f" work properly. Since
it terminates all outstanding RPCs on the mount point (and gets rid of all
state for NFSv4), this can be made to work well. (Mac OS X does this.)
A problem with this is that it can only be done by someone with system
priviledge. However, it seems to me that most systems are either personal 
(laptops or desktops) where the person has system priviledge OR systems 
running as servers in machine room environments. The latter usually have 
sysadmin monitoring and also tend to talk to NFS servers where
connectivity seldom goes away. As such, needing system priviledge doesn't 
seem too serious an issue to me.

Any other thoughts? rick