Greg Smith wrote:
> Kevin Grittner wrote:
> > 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
>
> It's in the docs now:
> http://www.postgresql.org/docs/9.0/s
Kevin Grittner wrote:
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
It's in the docs now:
http://www.postgresql.org/docs/9.0/static/wal-reliability.html
FLUSH
Kevin Grittner wrote:
> Bruce Momjian 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
> >> behavi
Bruce Momjian 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
Kevin Grittner wrote:
> Bruce Momjian 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
Bruce Momjian 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
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > On another topic, I am a little unclear on how things behave when
> > the drive is write-back. If the RAID controller card writes to the
> > drive, but the data isn't on the platers, how does it know when it
> > can discard that information from
Bruce Momjian wrote:
> On another topic, I am a little unclear on how things behave when
> the drive is write-back. If the RAID controller card writes to the
> drive, but the data isn't on the platers, how does it know when it
> can discard that information from the BBU RAID cache?
The control
Greg Smith wrote:
> Kevin Grittner wrote:
> > I've seen this, too (with xfs). Our RAID controller, in spite of
> > having BBU cache configured for writeback, waits for actual
> > persistence on disk for write barriers (unlike for fsync). This
> > does strike me as surprising to the point of borde
On Thu, 3 Jun 2010, Greg Smith wrote:
And it's also quite reasonable for a RAID controller to respond to that
"flush the whole cache" call by flushing its cache.
Remember that the RAID controller is presenting itself to the OS as a
large disc, and hiding the individual discs from the OS. Why s
Greg Smith wrote:
> I think this can only be resolved usefully for all of us at the
> RAID firmware level. If the controller had some logic that said
> "it's OK to not flush the cache when that call comes in if my
> battery is working fine", that would make this whole problem go
> away.
That
On Thu, Jun 3, 2010 at 1:31 PM, Greg Smith wrote:
> Scott Marlowe wrote:
>>
>> I think it's a case of the quickest, simplest answer to semi-new tech.
>> Not sure what to do with barriers? Just flush the whole cache.
>>
>
> Well, that really is the only useful thing you can do with regular SATA
>
Scott Marlowe wrote:
I think it's a case of the quickest, simplest answer to semi-new tech.
Not sure what to do with barriers? Just flush the whole cache.
Well, that really is the only useful thing you can do with regular SATA
drives; the ATA command set isn't any finer grained than that
Scott Marlowe wrote:
> I think it's a case of the quickest, simplest answer to semi-new
> tech. Not sure what to do with barriers? Just flush the whole
> cache.
>
> I'm guessing that this will get optimized in the future.
Let's hope so.
That reminds me, the write barrier concept is at lea
On Thu, Jun 3, 2010 at 12:40 PM, Kevin Grittner
wrote:
>
> Yeah, I read that long ago and I've disabled write barriers because
> of it; however, it still seems wrong that the RAID controller
> insists on flushing to the drives in write-back mode. Here are my
> reasons for wishing it was otherwise
Greg Smith wrote:
> Kevin Grittner wrote:
>> I've seen this, too (with xfs). Our RAID controller, in spite of
>> having BBU cache configured for writeback, waits for actual
>> persistence on disk for write barriers (unlike for fsync). This
>> does strike me as surprising to the point of borderin
Craig James wrote:
This is really hard to believe, because the bonnie++ numbers and dd(1)
numbers look good (see my original post). But it's totally
repeatable. It must be some really unfortunate "just missed the next
sector going by the write head" problem.
Commit performance is a separate
Kevin Grittner wrote:
I've seen this, too (with xfs). Our RAID controller, in spite of
having BBU cache configured for writeback, waits for actual
persistence on disk for write barriers (unlike for fsync). This
does strike me as surprising to the point of bordering on qualifying
as a bug.
Compl
Matthew Wakeling wrote:
> On Thu, 3 Jun 2010, Craig James wrote:
>>> Also, are barriers *on* on the RAID1 mount and off on the RAID10
one?
>>
>> It was the barriers. "barrier=1" isn't just a bad idea on ext4,
>> it's a disaster.
>
> This worries me a little. Does your array have a battery-backed
On Thu, 3 Jun 2010, Craig James wrote:
Also, are barriers *on* on the RAID1 mount and off on the RAID10 one?
It was the barriers. "barrier=1" isn't just a bad idea on ext4, it's a
disaster.
This worries me a little. Does your array have a battery-backed cache? If
so, then it should be fast
On 6/2/10 4:40 PM, Mark Kirkwood wrote:
On 03/06/10 11:30, Craig James wrote:
I'm testing/tuning a new midsize server and ran into an inexplicable
problem. With an RAID10 drive, when I move the WAL to a separate RAID1
drive, TPS drops from over 1200 to less than 90! I've checked
everything and c
Craig James wrote:
I'm testing/tuning a new midsize server and ran into an inexplicable
problem. With an RAID10 drive, when I move the WAL to a separate
RAID1 drive, TPS drops from over 1200 to less than 90!
Normally <100 TPS means that the write cache on the WAL drive volume is
disabled (or
On Wed, Jun 2, 2010 at 7:30 PM, Craig James wrote:
> I'm testing/tuning a new midsize server and ran into an inexplicable
> problem. With an RAID10 drive, when I move the WAL to a separate RAID1
> drive, TPS drops from over 1200 to less than 90! I've checked everything
> and can't find a reason
On 03/06/10 11:30, Craig James wrote:
I'm testing/tuning a new midsize server and ran into an inexplicable
problem. With an RAID10 drive, when I move the WAL to a separate
RAID1 drive, TPS drops from over 1200 to less than 90! I've checked
everything and can't find a reason.
Are the 2 n
I'm testing/tuning a new midsize server and ran into an inexplicable problem.
With an RAID10 drive, when I move the WAL to a separate RAID1 drive, TPS drops
from over 1200 to less than 90! I've checked everything and can't find a
reason.
Here are the details.
8 cores (2x4 Intel Nehalem 2 G
25 matches
Mail list logo
