On Wed, Apr 14, 2010 at 2:39 AM, Wichert Akkerman <wich...@wiggy.net> wrote:
> On 4/14/10 08:24 , Christian Theune wrote:
>> I'm pretty sure it's not. IIRC fsync is defined by POSIX and absolutely
>> requires the implementor to flush data physically to disk ensuring its
>> persistency. If that doesn't hold true then all transactions are borked.
> That was the problem with fsync on Linux: it effectively flushed all
> pending filesystem work, not just that for your current filehandle. That
> was needed to satisfy ordering constraints for the filesystem.
In theory, if you used a non-journaling file system, like ext2, then fsync would
only sync file given file. The few times I've looked, I didn't see a
to using ext2, but I suspect you'd have to have a pretty realistic
benchmark to see
the difference, if there is one. I suspect that the hit of fsync is
really mostly due to
the fact that you're really going to disk, rather than that you're
syncing things you
don't care about.
BTW, I suspect there's some opportunity to improve performance by somehow
doing the asynchronously. This would weaken durability, but not as much as not
doing fsync at all. There would generally be some benefit to allowing greater
parallelization of transaction commits.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org