9-STABLE -> NFS -> NetAPP:

[Rick Macklem]

Marc Fournier wrote:
> On 2013-02-14, at 08:41 , Rick Macklem <rmacklem at uoguelph.ca> wrote:
> 
> >
> > Btw Marc, if you just want this problem to go away, I suspect
> > getting rid
> > of the "intr" mount option would do that.
> 
> Am more interested in fixing the problem (if possible) then just
> masking it, but ...
> 
> Based on the man page for mount_nfs, wouldn't that have the opposite
> effect:
> 
> intr Make the mount interruptible, which implies that file
> system calls that are delayed due to an unresponsive
> server will fail with EINTR when a termination signal is
> posted for the process.
> 
> I may be mis-reading, but from the above it sounds like a -9 *should*
> terminate the process if intr is enabled, while with it disabled, it
> would ignore it … ?
> 
Yes, you have misread it (or english is a wonderfully ambiguous thing,
if you prefer;-).

For hard mounts (which is what you get if you don't specify either "soft"
nor "intr"), the RPCs behave like other I/O subsystems, which means they
do non-interruptible sleeps ("D" stat in ps) waiting for server replies
and continue to try and complete the RPC "forever". You can't kill off
the process/thread with any signal.

If "umount -f" of the filesystem works, that terminates the thread(s).
Unfortunately, "umount -f" is quite broken again. I have an idea on
how to resolve this, but I haven't coded it yet. (The problem is that
the process doing "umount -f" gets stuck before it does the VFS_UNMOUNT(),
so the NFS client doesn't see it.)

rick

> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"