Date: Thu, 14 Feb 2013 16:37:19 -0800 From: "Marc G. Fournier" <scrappy@hub.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Konstantin Belousov <kostikbel@gmail.com>, Kostik Belousov <kib@freebsd.org>, freebsd-stable@freebsd.org, John Baldwin <jhb@freebsd.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: Message-ID: <7614F404-CD69-479E-BDFA-31451DB9040F@hub.org> In-Reply-To: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> References: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-02-14, at 16:24 , Rick Macklem <rmacklem@uoguelph.ca> wrote:
> Marc Fournier wrote:
>> On 2013-02-14, at 08:41 , Rick Macklem <rmacklem@uoguelph.ca> wrote:
>>=20
>>>=20
>>> Btw Marc, if you just want this problem to go away, I suspect
>>> getting rid
>>> of the "intr" mount option would do that.
>>=20
>> Am more interested in fixing the problem (if possible) then just
>> masking it, but ...
>>=20
>> Based on the man page for mount_nfs, wouldn't that have the opposite
>> effect:
>>=20
>> 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.
>>=20
>> 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 =85 ?
>>=20
> Yes, you have misread it (or english is a wonderfully ambiguous thing,
> if you prefer;-).
>=20
> 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.
>=20
> 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 =85 ?
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 =85
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7614F404-CD69-479E-BDFA-31451DB9040F>