Re: Postgres fsync off (not needed) with NetApp

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, Dan Gorman <dgorman(at)hi5(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres fsync off (not needed) with NetApp
Date: 2006-06-15 15:54:20
Message-ID: 20060615155420.GK34196@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Jun 15, 2006 at 01:14:26AM -0400, Jonah H. Harris wrote:
> On 14 Jun 2006 23:33:53 -0400, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> >In fact the benefit of the NVRAM is precisely that it makes sure you
> >*don't*
> >have any reason to turn fsync off. It should make the fsync essentially
> >free.
>
> Having run PostgreSQL on a NetApp with input from NetApp, this is
> correct. fsync should be turned on, but you will not incur the *real*
> direct-to-disk cost of the sync, it will be direct-to-NVRAM.

Just so there's no confusion... this applies to any caching RAID
controller as well. You just need to ensure that the cache in the
controller absolutely will not be lost in the event of a power failure
or what-have-you. On most controllers this is accomplished with a simple
battery backup; I don't know if the higher-end stuff takes further steps
(such as flashing the cache contents to flash memory on a power
failure).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2006-06-15 15:57:36 Re: Test request for Stats collector performance improvement
Previous Message Jim C. Nasby 2006-06-15 15:50:00 Re: Confirmation of bad query plan generated by 7.4