Ok, I finally got a couple of tests done against CVS from Aug 3, 2005.
I'm not sure if I'm showing anything insightful though. I've learned
that fdatasync and O_DSYNC are simply fsync and O_SYNC respectively on
Linux, which you guys may have already known. There appears to be a
fair performance
Mark Wong wrote:
Ok, I finally got a couple of tests done against CVS from Aug 3, 2005.
I'm not sure if I'm showing anything insightful though. I've learned
that fdatasync and O_DSYNC are simply fsync and O_SYNC respectively on
Linux, which you guys may have already known. There appears to
Mark Wong wrote:
O_DIRECT + fsync() can make sense. It avoids the copying of data
to the page cache before being written and will also guarantee
that the file's metadata is also written to disk. It also
prevents the page cache from filling up with write data that
will never be read (I
Here are comments that Daniel McNeil made earlier, which I've neglected
to forward earlier. I've cc'ed him and Mark Havercamp, which some of
you got to meet the other day.
Mark
-
With O_DIRECT on Linux, when the write() returns the i/o has been
transferred to the disk.
Normally, this
Patch applied. Thanks.
---
ITAGAKI Takahiro wrote:
Thanks for reviewing!
But the patch does not work on HEAD, because of the changes in
BootStrapXLOG().
I send the patch with a fix for it.
Bruce Momjian
ITAGAKI Takahiro wrote:
Thanks for reviewing!
But the patch does not work on HEAD, because of the changes in
BootStrapXLOG().
I send the patch with a fix for it.
Thanks.
If you are doing fsync(), I don't see how O_DIRECT
makes any sense because O_DIRECT is writing to disk on every
I have modified and attached your patch for your review. I didn't see
any value to adding new fsync_method values because, to me, O_DIRECT is
basically just like O_SYNC except it doesn't keep a copy of the buffer
in the kernel cache. If you are doing fsync(), I don't see how O_DIRECT
makes any
