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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2006-02-28 21:15:31 Re: [PERFORM] temporary indexes
Previous Message Jim C. Nasby 2006-02-28 21:02:32 Re: [PERFORM] temporary indexes