Bruce Momjian <bruce@xxxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
