Greg Smith wrote:
On Wed, 13 Aug 2008, Ron Mayer wrote:
Second of all - ext3 fsync() appears to me to be *extremely* stupid.
It only seems to correctly do the correct flushing (and waiting) for a
drive's cache to be flushed when a file's inode has changed.
This is bad, but the way PostgreSQL uses fsync seems to work fine--if it
didn't, we'd all see unnaturally high write rates all the time.
But only if you turn off IDE drive caches.
What was new to me in these experiments is that if you touch the
inode as described here:
http://article.gmane.org/gmane.linux.file-systems/21373
then fsync() works and you can leave the IDE cache enabled; so
long as your drive supports the flush command -- which you can
see by looking for the drive in the output of:
%dmesg | grep 'disabling barriers'
JBD: barrier-based sync failed on md1 - disabling barriers
JBD: barrier-based sync failed on hda3 - disabling barriers
So I take back what I said about linux and write barriers
being sane. They're not.
Right. Where Linux seems to be at right now is that there's this
I almost fear I misphrased that. Apparently IDE drives
don't lie (the ones that don't support barriers let the OS
know that they don't). And apparently write barriers
do work.
It's just that ext3 only uses the write barriers correctly
on fsync() when an inode is touched, rather than any time
a file's data is touched.
then it seems buggy. I personally just ignore the fact that they exist
on ext3, and maybe one day ext4 will get this right.
+1
