Re: [HACKERS] fsync method checking

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(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:44:02
Message-ID: 11043.1079635442@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

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.

> 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.

> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-03-18 18:50:32 Re: [HACKERS] fsync method checking
Previous Message Bruce Momjian 2004-03-18 18:40:43 Re: fsync method checking

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2004-03-18 18:50:32 Re: [HACKERS] fsync method checking
Previous Message Bruce Momjian 2004-03-18 18:40:43 Re: fsync method checking