From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 11 12:38:22 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B487716A4BF; Thu, 11 Sep 2003 12:38:22 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0104843FEC; Thu, 11 Sep 2003 12:38:21 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id FAA20462; Fri, 12 Sep 2003 05:38:13 +1000 Date: Fri, 12 Sep 2003 05:38:12 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Eno Thereska In-Reply-To: <3F5FCEB5.9010407@andrew.cmu.edu> Message-ID: <20030912051818.B1339@gamplex.bde.org> References: <3F5FCEB5.9010407@andrew.cmu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-fs@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: flush on close X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2003 19:38:22 -0000 On Wed, 10 Sep 2003, Eno Thereska wrote: > In FreeBSD 4.4, I am noticing a huge number of calls > to ffs_fsync() (in /sys/ufs/ffs/ffs_vnops.c) > when running a benchmark like Postmark. > > ffs_fsync() flushes all dirty buffers with an open file > to disk. Normally this function would be called > either because the application writer explicitly > flushes the file, or if the syncer daemon or buffer daemon > decide it's time for the dirty blocks to go to disk. > > Neither of these two options is happening. Files are opened and closed > very frequently though. I have a suspicion that BSD is using the > "flush-on-close" semantic. > > Could someone confirm or reject this claim? > If confirmed, I am wondering how to get rid of it... ffs_fsync() is (or should be) rarely called except as a result of applications calling fsync(2) or sync(2). It is not normally called by the syncer daemon or buffer daemon (seems to be not at all in 4.4, though -current calls it from vfs-bio.c when there are too many dirty buffers, and benchmarks like postmark might trigger this). In 4.4 the only relevant VOP_FSYNC() seems to be the one in vinvalbuf(). Using lots of vnodes might cause this to be called a lot, but this should only cause a lot of i/o in ffs_fsync() if a lot is really needed. Dirty buffers for vnodes which will soon be deleted are supposed to be discarded in ffs_fsync(). Benchmarks that do lots of i/o to short-lived files tend to cause too much physical i/o, but this is because the i/o is done by the buffer (?) deamon before ffs_fsync() can discard it. Bruce