Re: fsync() Performance Issue

[Chris Mason <mason@suse.com>]

On Fri, 2002-05-03 at 22:05, Hans Reiser wrote:

> >The barrier option doesn't make much difference because the write cache
> >is off.  With write cache on, the barrier code should allow you to be
> >faster than with the caching off, but without risking the data (Jens and
> >I are working on final fsync safety issues though).
> >
> >Hans, data=journal turns on the data journaling.  The data journaling
> >
> and the reason it is faster is....

Any time you append X number of bytes followed by an fsync (or O_SYNC),
you trigger a commit for the modified metadata, and then a seek to write
the data block.  You wait on the log blocks (usually 5 or 6 of them
total in the transaction) and then you wait for the data block to hit
the main disk area.

With data logging, you also write the data block to the log, and that
means you can wait a while to flush it back to the main disk.  This
increases the size of the transaction by 1, but writing 7 blocks to the
log is almost no different from writing 6.

You don't have to seek back to the main disk until you need to flush the
transaction.  The new code also flushes metadata from more the one
transaction at once, leading to less waiting overall.

The new code is smarter about triggering updates to the journal header
block, it happens much less frequently now, leading to fewer seeks and
less waiting.

As the size of the O_SYNC/fsync write increases, the benefit goes down. 
A 16k write only gets around 30% improvement with the new patches. 
Since a 1k write still needs to write a whole block, it should be the
same speed as a 4k write.

Wayne, you might want to try the 1k test mounted with -o notail.

-chris