Re: [HACKERS] fsync method checking

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>,pgsql-performance(at)postgresql(dot)org,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] fsync method checking
Date: 2004-03-18 18:50:32
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers pgsql-performance

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > I have been poking around with our fsync default options to see if I can
> > improve them. One issue is that we never default to O_SYNC, but default
> > to O_DSYNC if it exists, which seems strange.
> As I recall, that was based on testing on some different platforms.
> It's not particularly "strange": O_SYNC implies writing at least two
> places on the disk (file and inode). O_DSYNC or fdatasync should
> theoretically be the fastest alternatives, O_SYNC and fsync the worst.

But why perfer O_DSYNC over fdatasync if you don't prefer O_SYNC over

> > Compare fsync before and after write's close:
> > write, fsync, close 0.000707
> > write, close, fsync 0.000808
> What does that mean? You can't fsync a closed file.

You reopen and fsync.

> > This shows terrible O_SYNC performance for 2 8k writes, but is faster
> > for a single 8k write. Strange.
> I'm not sure I believe these numbers at all... my experience is that
> getting trustworthy disk I/O numbers is *not* easy.

These numbers were reproducable on all the platforms I tested.

Bruce Momjian |
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to


Browse pgsql-performance by date

  From Date Subject
Next Message Michael Adler 2004-03-18 18:52:37 string casting for index usage
Previous Message Tom Lane 2004-03-18 18:44:02 Re: [HACKERS] fsync method checking

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2004-03-18 19:00:29 Re: syntax error position "CREATE FUNCTION" bug fix
Previous Message Tom Lane 2004-03-18 18:44:02 Re: [HACKERS] fsync method checking