This is a discussion on Re: flush on close - FreeBSD ; 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 ...
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"