From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 00:37:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 724EC45D; Fri, 15 Feb 2013 00:37:29 +0000 (UTC) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 2FD8E7BB; Fri, 15 Feb 2013 00:37:29 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 67CB61AD2FA6; Thu, 14 Feb 2013 20:37:22 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.188]) (amavisd-maia, port 10024) with ESMTP id 46509-04; Fri, 15 Feb 2013 00:37:22 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 2DCA31AD2FA5; Thu, 14 Feb 2013 20:37:21 -0400 (AST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: 9-STABLE -> NFS -> NetAPP: From: "Marc G. Fournier" In-Reply-To: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 14 Feb 2013 16:37:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7614F404-CD69-479E-BDFA-31451DB9040F@hub.org> References: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , Kostik Belousov , freebsd-stable@freebsd.org, John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 00:37:29 -0000 On 2013-02-14, at 16:24 , Rick Macklem wrote: > Marc Fournier wrote: >> On 2013-02-14, at 08:41 , Rick Macklem 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