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 t
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 d
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 a
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 i/o
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 w
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 ever
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 wrote:
> If you are doing fsync(), I don't see how O_DIRECT
> makes any sense because O_DIRECT is writing to disk on every write, and
> then wh
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 s
I think the conclusion from the discussion is that O_DIRECT is in
addition to the sync method, rather than in place of it, because
O_DIRECT doesn't have the same media write guarantees as fsync(). Would
you update the patch to do O_DIRECT in addition to O_SYNC or fsync() and
see if there is a per
On Fri, Jun 03, 2005 at 09:43:13 -0700,
Mary Edie Meredith <[EMAIL PROTECTED]> wrote:
>
> Looking at this from another angle, is there really any way that you can
> say a write is truly guaranteed in the event of a failure? I think in
> the end to be safe, you cannot. That's why (and I'm not t
On Fri, 2005-06-03 at 10:37 +1000, Neil Conway wrote:
> On Thu, 2005-06-02 at 11:49 -0700, Mary Edie Meredith wrote:
> > My understanding is that O_DIRECT means "direct" as in "no buffering by
> > the OS" which implies that if you write from your buffer, the write is
> > not going to return unless
On Thu, 2005-06-02 at 11:49 -0700, Mary Edie Meredith wrote:
> My understanding is that O_DIRECT means "direct" as in "no buffering by
> the OS" which implies that if you write from your buffer, the write is
> not going to return unless the OS thinks the write is completed
Right, I think that's d
On Thu, 2005-06-02 at 11:39 +1000, Neil Conway wrote:
> On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
> > I know I'm late to this discussion, and I haven't made it all the way
> > through this thread to see if your questions on Linux writes were
> > resolved. If you are still inter
On Wed, 2005-06-01 at 17:08 -0700, Mary Edie Meredith wrote:
> I know I'm late to this discussion, and I haven't made it all the way
> through this thread to see if your questions on Linux writes were
> resolved. If you are still interested, I recommend read a very good
> one page description of
On Mon, 2005-05-30 at 16:29 +1000, Neil Conway wrote:
> On Mon, 2005-05-30 at 10:59 +0900, ITAGAKI Takahiro wrote:
> > Yes, I've tested pgbench and dbt2 and their performances have improved.
> > The two results are as follows:
> >
> > 1. pgbench -s 100 on one Pentium4, 1GB mem, 2 ATA disks, Linux
On Mon, 2005-05-30 at 11:24 -0400, Tom Lane wrote:
> Wouldn't count on it :-(. One thing I'm particularly worried about is
> buffer cache consistency: does the kernel guarantee to flush any buffers
> it has that overlap the O_DIRECT write operation?
At least on Linux I believe the kernel guarante
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2005-05-30 at 02:52 -0400, Tom Lane wrote:
> Well, that claims that "data is guaranteed to have been transferred",
> but transferred to *where* is the question :)
Oh, I see what you are worried about. I think you are right: what the
doc promises i
On Mon, 2005-05-30 at 10:59 +0900, ITAGAKI Takahiro wrote:
> Yes, I've tested pgbench and dbt2 and their performances have improved.
> The two results are as follows:
>
> 1. pgbench -s 100 on one Pentium4, 1GB mem, 2 ATA disks, Linux 2.6.8
>(attached image)
> tps | wal_sync_method
> ---
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
is opening a file with O_DIRECT sufficient to ensure that
a write(2) does not return until the data has hit disk?
Some googling suggests so, eg
http://www.die.net/doc/linux/man/man2/open.2.html
Really? On that page I read:
"O_DIRECT..
On Mon, 2005-05-30 at 02:52 -0400, Tom Lane wrote:
> Some googling suggests so, eg
> http://www.die.net/doc/linux/man/man2/open.2.html
Well, that claims that "data is guaranteed to have been transferred",
but transferred to *where* is the question :) Transferring data to the
disk's buffers and the
Neil Conway <[EMAIL PROTECTED]> writes:
> I wonder if we're benchmarking the right thing, though: is
> opening a file with O_DIRECT sufficient to ensure that a write(2) does
> not return until the data has hit disk?
Some googling suggests so, eg
http://www.die.net/doc/linux/man/man2/open.2.html
T
Neil Conway <[EMAIL PROTECTED]> wrote:
> > The patch adds a new choice "open_direct" to wal_sync_method.
> Have you looked at what the performance difference of this option is?
Yes, I've tested pgbench and dbt2 and their performances have improved.
The two results are as follows:
1. pgbench -s
ITAGAKI Takahiro wrote:
The patch adds a new choice "open_direct" to wal_sync_method.
It uses O_DIRECT flags for WAL writes, like O_SYNC.
Have you looked at what the performance difference of this option is?
For example, these benchmark results seem to indicate that an older
version of the pa
This patch ticks off the following TODO items:
Consider use of open/fcntl(O_DIRECT) to minimize OS caching, especially for
WAL writes.
The patch adds a new choice "open_direct" to wal_sync_method.
It uses O_DIRECT flags for WAL writes, like O_SYNC.
I had sent a patch looked like this before
(
24 matches
Mail list logo
