handling unresonsive NFS servers

[Eric Anderson]

Rick Macklem wrote:
> 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

I agree with you 100%.  In datacenters that I have run, umount -f should 
always work (in my opinion), and should be a superuser privilege.  If I 
am root, and I say 'umount -f ...' - just do it.  NFS servers do go 
away, and sometimes you *have* to umount -f.  In linux, you can make 
that happen (mostly), but FreeBSD doesn't like it much.  Anyone who runs 
with soft mounts, or intr mounts, should be prepared for inconsistent 
data, or broken apps when there are NFS issues.  Typically I expect my 
hard mounts (non-interruptable) to stick, and applications to block, 
until the mount comes back.  If I need to remove the mount though, I 
want to be able to do it with a umount -f command, and have it 'just 
work', since I know the consequences.

Eric