From owner-freebsd-stable@FreeBSD.ORG Thu Feb 14 19:17:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 19CDB458; Thu, 14 Feb 2013 19:17:30 +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 DA34B810; Thu, 14 Feb 2013 19:17:29 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.188]) by hub.org (Postfix) with ESMTP id 4D4E4F14B6C; Thu, 14 Feb 2013 15:17:28 -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 58328-03; Thu, 14 Feb 2013 19:17:28 +0000 (UTC) Received: from [10.5.250.150] (remote.ilcs.sd63.bc.ca [142.31.148.2]) by hub.org (Postfix) with ESMTPA id 1525BF14B6B; Thu, 14 Feb 2013 15:17:26 -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: <1422247357.3019523.1360860105806.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 14 Feb 2013 11:17:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <66254EB1-3E15-4DBF-AFA6-FFB9AC7701DB@hub.org> References: <1422247357.3019523.1360860105806.JavaMail.root@erie.cs.uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1499) Cc: Konstantin Belousov , freebsd-stable@freebsd.org, Kostik Belousov , 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: Thu, 14 Feb 2013 19:17:30 -0000 On 2013-02-14, at 08:41 , Rick Macklem wrote: >=20 > 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 =85 ?