Re: Weird XFS WAL problem

Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)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).

Yeah. I wonder if it honors the cache flush because it might think it
is replacing disks or something odd. I think we are going to have to
document this in 9.0 because obviously you have seen it already.

Is this an issue with SAS cards/drives as well?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ None of us is going to be here forever. +