From: david@lang.hm
To: Aidan Van Dyk <aidan@highrise.ca>
Cc: Craig Ringer <ringerc@ringerc.id.au>
Cc: Ogden <lists@darkstatic.com>
Cc: pgsql-performance@postgresql.org, Greg Smith <greg@2ndquadrant.com>
Subject: Re: Raid 5 vs Raid 10 Benchmarks Using bonnie++
Date: Mon, 12 Sep 2011 15:57:48 -0700 (PDT)
Message-ID: <alpine.DEB.2.02.1109121555040.522@asgard.lang.hm> (raw)
In-Reply-To: <CAC_2qU97zU=v0MzOtPKe4A_1Kj6ySN-+=Jn1rcTSeW1Ya1pC_w@mail.gmail.com>
References: <959BD2FA-0312-458B-BD5F-ED358D2C47ED@darkstatic.com>
<f4e06a7cad34ee9217a3e57fd4eb0e67.squirrel@sq.gransy.com>
<D89151D3-D2E5-47E3-8B90-4A573DAB5FFA@darkstatic.com>
<75A85649-2B95-43D5-8404-4776D2E580EC@darkstatic.com>
<4E4C2FB4.4010409@2ndQuadrant.com>
<207E881B-73CD-4C31-A863-2C238838C41F@darkstatic.com>
<4E4CA4BC.9050908@ringerc.id.au>
<CAC_2qU97zU=v0MzOtPKe4A_1Kj6ySN-+=Jn1rcTSeW1Ya1pC_w@mail.gmail.com>
apologies for such a late response to this thread, but there is domething
I think is _really_ dangerous here.
On Thu, 18 Aug 2011, Aidan Van Dyk wrote:
> On Thu, Aug 18, 2011 at 1:35 AM, Craig Ringer <ringerc@ringerc.id.au> wrote:
>> On 18/08/2011 11:48 AM, Ogden wrote:
>>>
>>> Isn't this very dangerous? I have the Dell PERC H700 card - I see that it
>>> has 512Mb Cache. Is this the same thing and good enough to switch to
>>> nobarrier? Just worried if a sudden power shut down, then data can be lost
>>> on this option.
>>>
>>>
>> Yeah, I'm confused by that too. Shouldn't a write barrier flush data to
>> persistent storage - in this case, the RAID card's battery backed cache? Why
>> would it force a RAID controller cache flush to disk, too?
>
> The "barrier" is the linux fs/block way of saying "these writes need
> to be on persistent media before I can depend on them". On typical
> spinning media disks, that means out of the disk cache (which is not
> persistent) and on platters. The way it assures that the writes are
> on "persistant media" is with a "flush cache" type of command. The
> "flush cache" is a close approximation to "make sure it's persistent".
>
> If your cache is battery backed, it is now persistent, and there is no
> need to "flush cache", hence the nobarrier option if you believe your
> cache is persistent.
>
> Now, make sure that even though your raid cache is persistent, your
> disks have cache in write-through mode, cause it would suck for your
> raid cache to "work", but believe the data is safely on disk and only
> find out that it was in the disks (small) cache, and you're raid is
> out of sync after an outage because of that... I believe most raid
> cards will handle that correctly for you automatically.
if you don't have barriers enabled, the data may not get written out of
main memory to the battery backed memory on the card as the OS has no
reason to do the write out of the OS buffers now rather than later.
Every raid card I have seen has ignored the 'flush cache' type of command
if it has a battery and that battery is good, so you leave the barriers
enabled and the card still gives you great performance.
David Lang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: david@lang.hm, aidan@highrise.ca, ringerc@ringerc.id.au, lists@darkstatic.com, greg@2ndquadrant.com
Subject: Re: Raid 5 vs Raid 10 Benchmarks Using bonnie++
In-Reply-To: <alpine.DEB.2.02.1109121555040.522@asgard.lang.hm>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox