softupdates and two different MTAs

Dan Nelson dnelson at
Fri Mar 19 14:16:47 PST 2004

In the last episode (Mar 16), Claus Assmann said:
> | program       | FS               |  writes | reads |
> |---------------+------------------+---------+-------|
> | sm8.12.11     | UFS, softupdates |     236 |     0 |
> | sm8.12.11     | UFS, no su       |    8100 |     1 |
> | sm9.0.0.12    | UFS, softupdates |    3500 |     4 |
> | sm9.0.0.12    | UFS, no su       |    6300 |     0 |
> Question: why does sm8 use so few writes? Can softupdates eliminate
> or cluster most writes including fsync(2)? Why doesn't this work for
> sm9?

I'm not sure I understand any of those values :)  1000 mails requires
at least 3000 fsyncs, doesn't it, one each for qf, df, and tf?  And
each fsync should write two disk blocks (inode and data).

Without softupdates, that should be 12 IO/s per message:
create+2*fsync+unlink, once for each of df+qf+tf.  Total 12000 I/Os

With softupdates, it should be 6:  2*fsync, once for each of df+qf+tf. 
Total 6000 I/Os

So something is either not fsyncing, or there is clustering going on
behind the scenes.  The sm8 softupdates count is disturbingly low, even
assuming good clustering.

> I had the following idea why there are so many writes for sm9
> compared to sm8: sm9 has only one SMTP server process and since
> fsync(2) is synchronous the process has to wait for it to return. In
> sm8 there are many processes which can proceed independently and
> softupdates could reorder the operations and perform a "group
> commit", i.e., schedule multiple fsync(2) operations together and
> then a group of processes can proceed.

Theoretically possible.  If the files' inodes happen to be on the same
disk block, or if they are small messages and the frags happen to be in
the same disk block, then an fsync() on one may automatically sync the
other files for free.  I don't know enough about ffs or softupdates to
be able to tell from looking at the source though.  You might be able
to demonstrate that it's clustering by creating an fsync() wrapper that
gets read and write counts before and after the real fsync() call.  If
you ever call fsync but the I/O counts don't change, then you know that
something else synced the file already.

	Dan Nelson
	dnelson at

More information about the freebsd-fs mailing list