From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:15:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2939110656B1; Mon, 29 Jun 2009 15:15:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C048C8FC0C; Mon, 29 Jun 2009 15:15:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI93SEqDaFvL/2dsb2JhbADPDoQNBYE3 X-IronPort-AV: E=Sophos;i="4.42,309,1243828800"; d="scan'208";a="37749025" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2009 11:15:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 0BF828D4116; Mon, 29 Jun 2009 11:15:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoLeBH0J7Zfy; Mon, 29 Jun 2009 11:15:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 7F0ED8D4072; Mon, 29 Jun 2009 11:15:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5TFHKe12786; Mon, 29 Jun 2009 11:17:20 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Jun 2009 11:17:20 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Nathanael Hoyle In-Reply-To: <4A480B8C.1060708@hoyletech.com> Message-ID: References: <4A480B8C.1060708@hoyletech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:15:09 -0000 On Sun, 28 Jun 2009, Nathanael Hoyle wrote: > I think the answer is probably "it's a feature, not a bug", but that depends > on your NFS mount options which you didn't give. I'd suggest you read up on > NFS soft versus hard mounts. I think you're seeing the latter and expecting > the former behavior. > Well, part of the problem is that I'm working on a client that includes NFSv4 and, at least for NFSv4, getting "intr" or "soft" mounts to work correctly is nearly impossible. Since NFSv4 includes lock state operations that must be strictly serialized and the state maintained in a consistent way, you can't just "terminate" an RPC involving these Ops without breaking all state handling. Also, I/O system calls generally aren't expected to fail with EINTR and many (most??) apps. get broken by this happening. Personally, I believe that "hard" mounts plus the use of "umount -f" to get rid of mounts against unresponsive servers is the preferred way to go and the first step in this direction would be getting "umount -f" to work for the above case (plus agreement that the semantics of "umount -f" include "loss of recently written data"). There was a thread on this a few months ago, which I cant find, but there is pr129760 w.r.t. FreeBSD locking up upon a "umount -f". (Btw, I believe that Mac OS X has adopted this concept. It pops up a "disconnect mount" window for unresponsive servers and does essentially a "umount -f" if the user clicks "ok".) > The first hit I found Googling seems pretty decent, though taken from Linux > docs should still apply: > > http://tldp.org/HOWTO/NFS-HOWTO/client.html > > Under section 4.3.1 "Soft vs. Hard Mounting" there's a basic description. > There was a time when SunOS/Solaris was considered the "gold standard" for NFS (but I suppose this is the Linux era;-). My recollection might be fuzzy, but I don't think SunOS had a "umount -f" in those days and I think "intr" was introduced after their first release, as an improvement over "soft", since NFS servers got really slow when running on 1985 hardware. Solaris10 does have a "umount -f" and the man page notes that data related to open files can be lost when it is used. (This would basically be the semantic "umount -f" on FreeBSD will have if the "sync"s aren't done.) rick