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.
