Date: Thu, 14 Feb 2013 22:08:24 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: "Marc G. Fournier" <scrappy@hub.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-stable@freebsd.org, Kostik Belousov <kib@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <283687726.3041739.1360897704971.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <7614F404-CD69-479E-BDFA-31451DB9040F@hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marc Fournier wrote:
> On 2013-02-14, at 16:24 , Rick Macklem <rmacklem@uoguelph.ca> wrote:
>=20
> > Marc Fournier wrote:
> >> On 2013-02-14, at 08:41 , Rick Macklem <rmacklem@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 =E2=80=A6 ?
> >>
> > 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.)
>=20
> 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 =E2=80=A6 ?
>=20
> 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 =E2=80=A6
>=20
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
>=20
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?283687726.3041739.1360897704971.JavaMail.root>