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

From Bruce Momjian
Subject Re: Weird XFS WAL problem
Date
Msg-id 201006041530.o54FUAQ09934@momjian.us
Whole thread Raw
In response to Re: Weird XFS WAL problem  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Weird XFS WAL problem  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-performance
Kevin Grittner wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
> > Kevin Grittner wrote:
>
> >> The controller waits for the drive to tell it that it has made it
> >> to the platter before it discards it.  What made you think
> >> otherwise?
> >
> > Because a write-back drive cache says it is on the drive before it
> > hits the platters, which I think is the default for SATA drive.
> > Is that inaccurate?
>
> 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.  What is unique about the command ext4/xfs is sending?

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

pgsql-performance by date:

Previous
From: Marc Cousin
Date:
Subject: Re: performance regression with Linux 2.6.33 and glibc 2.12
Next
From: "Kevin Grittner"
Date:
Subject: Re: Weird XFS WAL problem