From owner-svn-src-all@FreeBSD.ORG Fri Jan 27 09:18:44 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9E58106566C; Fri, 27 Jan 2012 09:18:44 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2BD8FC13; Fri, 27 Jan 2012 09:18:43 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q0R9IJle030380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jan 2012 20:18:42 +1100 Date: Fri, 27 Jan 2012 20:18:19 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem In-Reply-To: <1513888354.186214.1327592563003.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: <20120127195645.G1604@besplex.bde.org> References: <1513888354.186214.1327592563003.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, Rick Macklem , svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans Subject: Re: svn commit: r230516 - in head/sys: fs/nfsclient nfsclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 09:18:44 -0000 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. 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