From owner-svn-src-head@FreeBSD.ORG Fri Jan 27 16:33:41 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3A49106564A; Fri, 27 Jan 2012 16:33:41 +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 1AB898FC16; Fri, 27 Jan 2012 16:33:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOrQIk+DaFvO/2dsb2JhbABDhQuqS4FyAQEEASMEUgUWDgoCAg0ZAlkGiA+mVZFZgS+HYQEFAxwEAQsBCAEGBAMDBBAVgmYFAwMBAgcDFQEFCwcCAYEbCYIegRYEiD+MW5Jr X-IronPort-AV: E=Sophos;i="4.71,580,1320642000"; d="scan'208";a="153999910" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 27 Jan 2012 11:33:39 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id E92E0B40D2; Fri, 27 Jan 2012 11:33:39 -0500 (EST) Date: Fri, 27 Jan 2012 11:33:39 -0500 (EST) From: Rick Macklem To: Bruce Evans Message-ID: <1072010695.266929.1327682019937.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20120127195645.G1604@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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: svn-src-head@FreeBSD.org, Rick Macklem , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 16:33:41 -0000 Bruce Evans wrote: > On Thu, 26 Jan 2012, Rick Macklem wrote: > > > Bruce Evans wrote: > > > >> Doesn't umount -f have to wait for i/o anyway? When it closes > >> files, > >> it must wait for all in-progress i/o for the files, and for all new > >> i/o's that result from closing. > >> > > umount -f kills off RPCs in progress. There was an email discussion > > about this, where it seemed there was no advantage in defining a > > separate "hard forced dismount" for this case. > > But umount -f means to close the files, not to lose their contents. > nfs umount should give a best effort not to lose any contents by > waiting > a bit. Maybe it already does. I saw some of the discussion. > Well, maybe in theory, but in practice, I don't think it makes much difference. I can think of 2 scenarios where a sysadmin might use "umount -f" on an NFS mount point: 1 - The NFS server is unresponsive (crashed or network partitioned) and the sysadmin can't wait until it comes back online. --> waiting a fraction of a second won't have any effect on the outcome unless the server comes back online within that fraction of a second. Since the sysadmin isn't willing to wait... 2 - The sysadmin needs to unmount the file system now, but some program has file(s) open on the mount point, so a normal unmount fails with EBUSY. --> Any programs with file(s) open for writing on the mount, will have those opens arbitrarily closed and subsequent write attempts will fail. As such, the programs won't be able to get the data written. (Yes, you could argue that the program was just finishing doing any writing it wanted to do and waiting a fraction of a second would allow it to complete, but that's basically the same argument as for #1.) No different than the sysadmin waiting a fraction of a second longer before they type "umount -f /mnt" from what I see. rick > BTW, I just replied to the POSIX list about close() returning EINTR. > POSIX has the silly specification that close() shall not discard any > ouput for a terminal device file [although an endless wait may be > required for that] but no similar detail for much more important types > of files. unmount() is better behaved than close() here since it can > and does actually handle cached data correctly by failing when there > is an i/o error writing it. > > Bruce