Ric Wheeler wrote: > > 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.
Yes, that was our idea. It needs just a little bit of API coding.... and it will be there..... but of course we are all focused on getting ready for the merge. > > 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. >> >> > >
