flush on close

[Bruce Evans]

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