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

Re: [HACKERS] O_DIRECT for WAL writes

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Mark Wong <markw(at)osdl(dot)org>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>,pgsql-patches(at)postgresql(dot)org, Daniel McNeil <daniel(at)osdl(dot)org>,Mark Haverkamp <markh(at)osdl(dot)org>
Subject: Re: [HACKERS] O_DIRECT for WAL writes
Date: 2005-08-09 22:21:00
Message-ID: 200508092221.j79ML0j01069@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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 assume it is only read if a recovery
> is necessary - which should be rare).  It can also
> helps disks with write back cache when using the journaling
> file system that use i/o barriers.  You would want to use
> large writes, since the kernel page cache won't be writing
> multiple pages for you.

Right, but it seems O_DIRECT is pretty much the same as O_DIRECT with
O_DSYNC because the data is always written to disk on write().  Our
logic is that there is nothing for fdatasync to do in most cases after
using O_DIRECT, so the O_DIRECT/fdatasync() combination doesn't make
sense.

And FreeBSD, and perhaps others, need O_SYNC or fdatasync with O_DIRECT
because O_DIRECT doesn't force stuff to disk in all cases.

> I need to look at the kernel code more to comment on O_DIRECT with
> O_SYNC.
> 
> Questions:
> 
> Does the database transaction logger preallocate the log file?

Yes.

> Does the logger care about the order in which each write hits the disk?

Not really.

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

pgsql-hackers by date

Next:From: Andrew - SupernewsDate: 2005-08-10 01:09:32
Subject: Re: Simplifying wal_sync_method
Previous:From: David FetterDate: 2005-08-09 22:04:47
Subject: Re: small proposal: pg_config record flag variables?

pgsql-patches by date

Next:From: Simon RiggsDate: 2005-08-09 22:28:01
Subject: Remove all trace of EXPLAIN EXECUTE
Previous:From: joshua masikoDate: 2005-08-09 19:40:27
Subject: BUG #1815: ECPGdebug causes crash on Windows XP

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