Skip site navigation (1) Skip section navigation (2)

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
Message-ID: 200403181850.i2IIoWo11126@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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
fsync?

> 	
> > 	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                        |  http://candle.pha.pa.us
  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

Responses

pgsql-performance by date

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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group