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 big advantage 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. Jim -- Jim Fulton _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
