Marc Fournier wrote:
> On 2013-02-14, at 16:24 , Rick Macklem <rmack...@uoguelph.ca> wrote:
>
> > Marc Fournier wrote:
> >> On 2013-02-14, at 08:41 , Rick Macklem <rmack...@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.)
>
> For how infrequently this problem generally manifests itself, is there
> an overall benefit from a debugging standpoint of my leaving intr on
> and reporting when it happens, including procstat output, and then
> upgrading to latest kernel … ?
>
> Its an annoyance, but it isn't like it happens daily, so I don't mind
> going through the process *towards* having it fixed if there is an
> overall benefit …
>
Well, hopefully kib and/or jhb can make some progress w.r.t. this.
I'll let them weigh in on what to do next, rick
>
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscr...@freebsd.org"
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
