Date: Fri, 12 Sep 2003 05:38:12 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Eno Thereska <eno@andrew.cmu.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: flush on close Message-ID: <20030912051818.B1339@gamplex.bde.org> In-Reply-To: <3F5FCEB5.9010407@andrew.cmu.edu> References: <3F5FCEB5.9010407@andrew.cmu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030912051818.B1339>