pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Greg Smith <greg@2ndquadrant.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: Craig James <craig_james@emolecules.com>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Weird XFS WAL problem
Date: Thu, 03 Jun 2010 14:18:34 -0400
Message-ID: <4C07F1FA.8010909@2ndquadrant.com> (raw)
In-Reply-To: <4C07A0830200002500031E74@gw.wicourts.gov>
References: <AANLkTikS_QvlkYfv5_hbsXFH4SsTh1nP_WoTwRqpUUcz@mail.gmail.com>
	<AANLkTikegoyBvJXhqZGLZyTwRVyBs4qCuCQ7d1Vntk4w@mail.gmail.com>
	<AANLkTikjkEvj2hG-D1CMu49PQXXbxHVzpXm9JbLWzMQo@mail.gmail.com>
	<AANLkTimtdk11hrWd-OpvXGLrh-4pukGd9eHEUemEM3OR@mail.gmail.com>
	<AANLkTinAhrwwwQKh6NrX-nnvcpxT1EFFlZrUxhaDB87C@mail.gmail.com>
	<AANLkTinuOUTbuke9FTMtwSObcZBio0uOS1ysWrqFyK3t@mail.gmail.com>
	<4C06E994.2080905@emolecules.com>
	<4C06EC01.3060506@catalyst.net.nz>
	<4C07E103.9020909@emolecules.com>
	<alpine.DEB.2.00.1006031811340.4083@aragorn.flymine.org>
	<4C07A0830200002500031E74@gw.wicourts.gov>

Kevin Grittner wrote:
> I've seen this, too (with xfs).  Our RAID controller, in spite of
> having BBU cache configured for writeback, waits for actual
> persistence on disk for write barriers (unlike for fsync).  This
> does strike me as surprising to the point of bordering on qualifying
> as a bug.
Completely intentional, and documented at 
http://xfs.org/index.php/XFS_FAQ#Q._Should_barriers_be_enabled_with_storage_which_has_a_persistent_w...

The issue is that XFS will actually send the full "flush your cache" 
call to the controller, rather than just the usual fsync call, and that 
eliminates the benefit of having a write cache there in the first 
place.  Good controllers respect that and flush their whole write cache 
out.  And ext4 has adopted the same mechanism.  This is very much a good 
thing from the perspective of database reliability for people with 
regular hard drives who don't have a useful write cache on their cheap 
hard drives.  It allows them to keep the disk's write cache on for other 
things, while still getting the proper cache flushes when the database 
commits demand them.  It does mean that everyone with a non-volatile 
battery backed cache, via RAID card typically, needs to turn barriers 
off manually.

I've already warned on this list that PostgreSQL commit performance on 
ext4 is going to appear really terrible to many people.  If you 
benchmark and don't recognize ext3 wasn't operating in a reliable mode 
before, the performance drop now that ext4 is doing the right thing with 
barriers looks impossibly bad.

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us




view thread (25+ messages)  latest in thread

Message-ID: <4C07F1FA.8010909@2ndquadrant.com>
Permalink:  ../4C07F1FA.8010909@2ndquadrant.com/
Also on:    postgresql.org/message-id/4C07F1FA.8010909@2ndquadrant.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: greg@2ndquadrant.com, Kevin.Grittner@wicourts.gov, craig_james@emolecules.com, matthew@flymine.org
  Subject: Re: Weird XFS WAL problem
  In-Reply-To: <4C07F1FA.8010909@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox