Re: fsync() Performance Issue

[Hans Reiser <reiser@namesys.com>]

Chris Mason wrote:

>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
>
>
>
>
>  
>
So how about if you revise fsync so that it always sends data blocks to 
the journal not to the main disk?

Hans