Kevin Grittner wrote: > 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). 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@xxxxxxxxxx> http://momjian.us EnterpriseDB http://enterprisedb.com + None of us is going to be here forever. + -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
