Re: Advice configuring ServeRAID 8k for performance

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Justin Pitts <justinpitts(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot) org" <pgsql-performance(at)postgresql(dot)org>, Matthew Wakeling <matthew(at)flymine(dot)org>, Pierre C <lists(at)peufeu(dot)com>, Kenneth Cox <kenstir(at)gmail(dot)com>
Subject: Re: Advice configuring ServeRAID 8k for performance
Date: 2010-08-06 17:59:05
Message-ID: AANLkTim=jj48gTiaNeA0FN0UiUgxGFfQ4p_5NcSzb2SR@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Aug 6, 2010 at 11:32 AM, Justin Pitts <justinpitts(at)gmail(dot)com> wrote:
>>>> As others said, RAID6 is RAID5 + a hot spare.
>>>
>>> No. RAID6 is NOT RAID5 plus a hot spare.
>>
>> The original phrase was that RAID 6 was like RAID 5 with a hot spare
>> ALREADY BUILT IN.
>
> Built-in, or not - it is neither. It is more than that, actually. RAID
> 6 is like RAID 5 in that it uses parity for redundancy and pays a
> write cost for maintaining those parity blocks, but will maintain data
> integrity in the face of 2 simultaneous drive failures.

Yes, I know that. I am very familiar with how RAID6 works. RAID5
with the hot spare already rebuilt / built in is a good enough answer
for management where big words like parity might scare some PHBs.

> In terms of storage cost, it IS like paying for RAID5 + a hot spare,
> but the protection is better.
>
> A RAID 5 with a hot spare built in could not survive 2 simultaneous
> drive failures.

Exactly. Which is why I had said with the hot spare already built in
/ rebuilt. Geeze, pedant much?

--
To understand recursion, one must first understand recursion.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Justin Pitts 2010-08-06 18:17:18 Re: Advice configuring ServeRAID 8k for performance
Previous Message Justin Pitts 2010-08-06 17:32:18 Re: Advice configuring ServeRAID 8k for performance