From owner-svn-src-all@FreeBSD.ORG Mon May 30 19:34:44 2011 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 0739B1065676; Mon, 30 May 2011 19:34:44 +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 594D38FC0C; Mon, 30 May 2011 19:34:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAAvx402DaFvO/2dsb2JhbABVhEmiWIhxqneQNIErg2yBBwSQT482 X-IronPort-AV: E=Sophos;i="4.65,293,1304308800"; d="scan'208";a="126294906" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 May 2011 15:34:37 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id EF0C2B3F2B; Mon, 30 May 2011 15:34:37 -0400 (EDT) Date: Mon, 30 May 2011 15:34:37 -0400 (EDT) From: Rick Macklem To: Robert Watson Message-ID: <1822018328.1016204.1306784077970.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) 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-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: Mon, 30 May 2011 19:34:44 -0000 > > 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. > Well, I suppose write latency will often be higher for NFS than other mount points. The case where I think the sync(2) might help from a performance point of view might be (I'm talking through my hat here. Haven't benchmarked or looked at it closely and don't intend to:-): - does a "umount -a" when there are a lot of /etc/fstab entries with a lot of dirty blocks to be written out. --> the writes would be started for all file systems and then they would be unmount(2)'d one at a time. It might be quite a while before the last fs gets an unmount(2), so the blocks "might" have been written out by then. on the other hand, take the above example and replace "umount -a" with "umount /x" where "/x" is a single fs with no dirty blocks and... --> for this one, the sync(2) would just slow it down, by going through all the other fs's... rick