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

Re: Mount options for Ext3?

From: pgsql(dot)spam(at)vinz(dot)nl
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Mount options for Ext3?
Date: 2003-01-25 23:21:54
Message-ID: 20030125232154.GK14898@md2.mediadesign.nl (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
On 2003-01-24 21:58:55 -0500, Tom Lane wrote:
> The key assumption we are making about the filesystem's behavior is that
> writes scheduled by the sync() will occur before the pg_control write
> that's issued after it.  People have occasionally faulted this algorithm
> by quoting the sync() man page, which saith (in the Gospel According To
> HP)
> 
>      The writing, although scheduled, is not necessarily complete upon
>      return from sync.
> 
> This, however, is not a problem in itself.  What we need to know is
> whether the filesystem will allow writes issued after the sync() to
> complete before those "scheduled" by the sync().
> 

Certain linux 2.4.* kernels (not sure which, newer ones don't seem to have 
it) have the following kernel config option:

Use the NOOP Elevator (WARNING)
CONFIG_BLK_DEV_ELEVATOR_NOOP
  If you are using a raid class top-level driver above the ATA/IDE core,
  one may find a performance boost by preventing a merging and re-sorting
  of the new requests.

  If unsure, say N.

If one were certain his OS wouldn't do any re-ordering of writes, would it be
safe to run with fsync = off? (not that I'm going to try this, but I'm just
curious)


Vincent van Leeuwen
Media Design

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2003-01-26 05:27:51
Subject: Re: [PERFORM] Proposal: relaxing link between explicit JOINs and execution order
Previous:From: Ron JohnsonDate: 2003-01-25 19:19:09
Subject: Re: LOCK TABLE & speeding up mass data loads

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-01-26 01:00:22
Subject: Re: copying perms to another user
Previous:From: Dave CramerDate: 2003-01-25 22:46:38
Subject: interactive docs error

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