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).
-Kevin