Re: fs_mark benchmark - update

[Ric Wheeler <ric@emc.com>]

Since you still are in the thinking stage, there are some neat tricks 
that you might be able to do in this space ;-)

One thing that I think might be very interesting is to export some of 
the transaction like semantics explicitely to applications to allow a 
type of bulk async fsync. For example, I am untarring a 10,000 file set 
into a directory - you want a hard promise that it is all on disk, but 
you really don't need that promise until the end of the application.  If 
the application could flag the start of this kind of batch and then wait 
or kick off a group fsync at the end, you could really boost your 
performance.

The benchmark has some kludgy support for testing this kind of sync 
performance through the "-S X" flag.  When X==0, you don't sync, when it 
is 1 you do the file at a time fsync, and then it does some other 
combinations that work well on reiserfs.  By simply delaying the fsync() 
stage into a separate iteration over the file set, you can approach the 
non-fsynced behavior ;-)

ric


Hans Reiser wrote:

>reiser4 will suck at fsync performance, I guarantee it.  fsync is
>completely unoptimized.  It works reliably, but it will be slow. 
>
>The suckage is all eminently fixable,  but not before vanilla inclusion
>is resolved will we address it.
>  
>