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

Re: fsync and battery-backed caches

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Javier Somoza <jsomoza(at)pandasoftware(dot)es>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,Tino Wildenhain <tino(at)wildenhain(dot)de>,pgsql-performance(at)postgresql(dot)org
Subject: Re: fsync and battery-backed caches
Date: 2006-02-28 21:09:25
Message-ID: 20060228210925.GX82012@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-performance
Ok, you absolutely can't guarantee you won't get partial page writes
then. A UPS buys you no more data safety than being plugged directly
into the wall. UPS's fail. People trip over cords. Breakers fail. Even
if you have multiple power supplies on multiple circuits fed by
different UPS's you can *still* have unexpected power failures. The
'master' for distributed.net had exactly that happen recently; the two
breakers feeding it (from 2 seperate UPS's) failed simultaneously.

In a nutshell, having a server on a UPS is notthing at all like having a
BBU on the raid controller: commiting to the BBU is essentially the same
as committing to the drives, unless the BBU runs out of power before the
server has power restored, or fails in some similar fasion. But because
there's many fewer parts involved, such a failure of the BBU is far less
likely than a failure up-stream.

So, if you want performance, get a controller with a BBU and allow it to
cache writes. While you're at it, try and get one that will
automatically disable write caching if the BBU fails for some reason.

On Tue, Feb 28, 2006 at 06:27:34PM +0100, Javier Somoza wrote:
> 
>             Ups sorry.
> 
> 
> > Actually, you can't assume that a BBU means you can safely disable
> > full-page-writes. Depending on the controller, it's still possible to
> > end up with partially written pages.
> > 
> > BTW, if your mailer makes doing so convenient, it would be nice to trim
> > down your .signature; note that it's about 3x longer than the email you
> > actually sent.
> 
> 

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

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2006-02-28 21:15:31
Subject: Re: [PERFORM] temporary indexes
Previous:From: Jim C. NasbyDate: 2006-02-28 21:02:32
Subject: Re: [PERFORM] temporary indexes

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