Re: Weird XFS WAL problem - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Weird XFS WAL problem
Date
Msg-id 4C08D7070200002500031F66@gw.wicourts.gov
Whole thread Raw
In response to Re: Weird XFS WAL problem  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Weird XFS WAL problem
Re: Weird XFS WAL problem
List pgsql-performance
Bruce Momjian <bruce@momjian.us> wrote:
> Kevin Grittner wrote:

>> Any decent RAID controller will ensure that the drives themselves
>> aren't using write-back caching.  When we've mentioned write-back
>> versus write-through on this thread we've been talking about the
>> behavior of the *controller*.  We have our controllers configured
>> to use write-back through the BBU cache as long as the battery is
>> good, but to automatically switch to write-through if the battery
>> goes bad.
>
> OK, good, but when why would a BBU RAID controller flush stuff to
> disk with a flush-all command?  I thought the whole goal of BBU
> was to avoid such flushes.

That has been *precisely* my point.

I don't know at the protocol level; I just know that write barriers
do *something* which causes our controllers to wait for actual disk
platter persistence, while fsync does not.

The write barrier concept seems good to me, and I wish it could be
used at the OS level without killing performance.  I blame the
controller, for not treating it the same as fsync (i.e., as long as
it's in write-back mode it should treat data as persisted as soon as
it's in BBU cache).

-Kevin

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Weird XFS WAL problem
Next
From: Bruce Momjian
Date:
Subject: Re: Weird XFS WAL problem