Re: Weird XFS WAL problem
От | Kevin Grittner |
---|---|
Тема | Re: Weird XFS WAL problem |
Дата | |
Msg-id | 4C08D7070200002500031F66@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Weird XFS WAL problem (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Weird XFS WAL problem
Re: Weird XFS WAL problem |
Список | pgsql-performance |
Bruce Momjian <bruce@momjian.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
В списке pgsql-performance по дате отправления: