From owner-svn-src-head@FreeBSD.ORG Mon May 30 18:24:16 2011 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 67B8C106564A; Mon, 30 May 2011 18:24:16 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 41E288FC15; Mon, 30 May 2011 18:24:16 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id ED4C446B39; Mon, 30 May 2011 14:24:15 -0400 (EDT) Date: Mon, 30 May 2011 19:24:15 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Rick Macklem In-Reply-To: <336367081.983085.1306763929731.JavaMail.root@erie.cs.uoguelph.ca> Message-ID: References: <336367081.983085.1306763929731.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kostik Belousov , Rick Macklem , svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r222466 - head/sbin/umount 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: Mon, 30 May 2011 18:24:16 -0000 On Mon, 30 May 2011, Rick Macklem wrote: > Hehe. I'm so old, I do two syncs, as required by 6th Edition.:-) > > I assumed the sync() was meant to be an optimization (given the comment for > it) in the sense that it would get the writes of dirty blocks started "right > away". However, given the short period of time from the the sync(2) call to > the unmount(2) call, I'm not convinced it makes a significant difference. (I > thought of just getting rid of it, but figured it was harmless for the non > "-f" case and might matter for a buggy fs that doesn't get the unmount(2) > quite right. ie. Same argument as doing the triple-sync, just to be sure.) If it masks, for example, lateny for a synchronous RPC to the remote mountd to deregister the mountpoint, allowing a cache flush and unmount to take place concurrently, that might be a useful benefit. I'm not sure I see any evidence that is the case in the source code, however. Robert