From owner-freebsd-stable@FreeBSD.ORG Fri Feb 15 00:24:47 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 497EC2DA; Fri, 15 Feb 2013 00:24:47 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BD30175F; Fri, 15 Feb 2013 00:24:46 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAMF/HVGDaFvO/2dsb2JhbABFhkm6L3OCHwEBAQQBAQEgBCcgCxsYAgINGQIpAQkmBggHBAEcBIdxDKphkjWBI4wngyeBEwOIZosLgjOBHY82gyVPgQU1 X-IronPort-AV: E=Sophos;i="4.84,668,1355115600"; d="scan'208";a="16767392" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 14 Feb 2013 19:24:40 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 38460B4036; Thu, 14 Feb 2013 19:24:40 -0500 (EST) Date: Thu, 14 Feb 2013 19:24:40 -0500 (EST) From: Rick Macklem To: "Marc G. Fournier" Message-ID: <761286247.3039021.1360887880184.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <66254EB1-3E15-4DBF-AFA6-FFB9AC7701DB@hub.org> Subject: Re: 9-STABLE -> NFS -> NetAPP: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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:24:47 -0000 Marc Fournier wrote: > 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. >=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 =E2=80=A6 ? >=20 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.) 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"