possible NFS lockups

[Rick Macklem]

> From: "Sam Fourman
> On Tue, Jul 27, 2010 at 10:29 AM, krad <kraduk at googlemail.com> wrote:
> > I have a production mail system with an nfs backend. Every now and
> > again we
> > see the nfs die on a particular head end. However it doesn't die
> > across all
> > the nodes. This suggests to me there isnt an issue with the filer
> > itself and
> > the stats from the filer concur with that.
> >
> > The symptoms are lines like this appearing in dmesg
> >
> > nfs server 10.44.17.138:/vol/vol1/mail: not responding
> > nfs server 10.44.17.138:/vol/vol1/mail: is alive again
> >
> > trussing df it seems to hang on getfsstat, this is presumably when
> > it tries
> > the nfs mounts
> >
> 
> I also have this problem, where nfs locks up on a FreeBSD 9 server
> and a FreeBSD RELENG_8 client
> 
If by RELENG_8, you mean 8.0 (or pre-8.1), there are a number
of patches for the client side krpc. They can be found at:
    http://people.freebsd.org/~rmacklem/freebsd8.0-patches

(These are all in FreeBSD8.1, so ignore this if your client is
already running FreeBSD8.1.)

rick
ps: "lock up" can mean many things. The more specific you can
    be w.r.t. the behaviour, the more likely it can be resolved.
    For example:
    - No more access to the subtree under the mount point is
      possible until the client is rebooted. When a "ps axlH"
      one process that was accessing a file in the mount point
      is shown with WCHAN rpclock and STAT DL.
    vs
    - All access to the mount point stops for about 1minute
      and then recovers.

    Also, showing what mount options are being used by the
    client and whether or not rpc.lockd and rpc.statd are
    running can also be useful.
    And if you can look at the net ttraffic with wireshark
    when it is locked up and see if any NFS traffic is
    happening can also be useful.