Re: [PERFORM] Arguments Pro/Contra Software Raid

From: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
To: Steve Atkins <steve(at)blighty(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>, "Pgsql-Performance ((E-mail))" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [PERFORM] Arguments Pro/Contra Software Raid
Date: 2006-05-09 19:04:08
Message-ID: 1147201448.9755.16.camel@state.g2switchworks.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Tue, 2006-05-09 at 12:52, Steve Atkins wrote:
> On May 9, 2006, at 8:51 AM, Joshua D. Drake wrote:
>
> ("Using SATA drives is always a bit of risk, as some drives are lying
> about whether they are caching or not.")
>
> >> Don't buy those drives. That's unrelated to whether you use hardware
> >> or software RAID.
> >
> > Sorry that is an extremely misleading statement. SATA RAID is
> > perfectly acceptable if you have a hardware raid controller with a
> > battery backup controller.
>
> If the drive says it's hit the disk and it hasn't then the RAID
> controller
> will have flushed the data from its cache (or flagged it as correctly
> written). At that point the only place the data is stored is in the non
> battery backed cache on the drive itself. If something fails then you'll
> have lost data.
>
> You're not suggesting that a hardware RAID controller will protect
> you against drives that lie about sync, are you?

Actually, in the case of the Escalades at least, the answer is yes.
Last year (maybe a bit more) someone was testing an IDE escalade
controller with drives that were known to lie, and it passed the power
plug pull test repeatedly. Apparently, the escalades tell the drives to
turn off their cache. While most all IDEs and a fair number of SATA
drives lie about cache fsyncing, they all seem to turn off the cache
when you ask.

And, since a hardware RAID controller with bbu cache has its own cache,
it's not like it really needs the one on the drives anyway.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2006-05-09 19:08:40 Re: pg_dump and grants to PUBLIC
Previous Message Wayne Conrad 2006-05-09 18:51:38 Re: A better AND query?

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-05-09 19:13:01 Re: [HACKERS] Big IN() clauses etc : feature proposal
Previous Message Joshua D. Drake 2006-05-09 18:43:16 Re: [PERFORM] Arguments Pro/Contra Software Raid