From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Craig James <craig_james(at)emolecules(dot)com>, Matthew Wakeling <matthew(at)flymine(dot)org>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Weird XFS WAL problem |
Date: | 2010-06-04 15:30:10 |
Message-ID: | 201006041530.o54FUAQ09934@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Kevin Grittner wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-06-04 15:35:51 | Re: Weird XFS WAL problem |
Previous Message | Marc Cousin | 2010-06-04 15:29:04 | Re: performance regression with Linux 2.6.33 and glibc 2.12 |