Re: What is the best way to storage music files in Postgresql - Mailing list pgsql-performance

From david@lang.hm
Subject Re: What is the best way to storage music files in Postgresql
Date
Msg-id alpine.DEB.1.00.0803181606140.21250@asgard.lang.hm
Whole thread Raw
In response to Re: What is the best way to storage music files in Postgresql  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: What is the best way to storage music files in Postgresql
List pgsql-performance
On Wed, 19 Mar 2008, Craig Ringer wrote:

> david@lang.hm wrote:
>> you can? I've never seen a raid 5 setup with more then a single parity
>> dirve (or even the option of having more then one drives worth of
>> redundancy). you can have hot-spare drives, but thats a different thing.
>>
> With RAID 4, where the "parity drives"  are in fact dedicated to parity
> information, the controller could just store the parity data mirrored on more
> than one drive. Unfortunately write performance on RAID 4 is absolutely
> horrible, and a second or third parity disk would not help with that.
>
> I suppose there's nothing stopping a controller adding a second disk's worth
> of duplicate parity information when striping a four or more disk RAID 5
> array, but I thought that's basically what RAID 6 was.

just duplicating the Raid 4 or 5 pairity information will not help you if
the parity drive is not one of the drives that fail.

raid 6 uses a different pairity algorithm so that any two drives in the
array can fail with no data loss.

even this isn't completely error proof. I just went through a scare with a
15 disk array where it reported 3 dead drives after a power outage. one of
the dead drives ended up being the hot-spare, and another drive that acted
up worked well enough to let me eventually recover all the data (seek
errors), but it was a very scary week while I worked through this.

David Lang

pgsql-performance by date:

Previous
From: Craig Ringer
Date:
Subject: Re: What is the best way to storage music files in Postgresql
Next
From: KC ESL
Date:
Subject: Re: Planner mis-estimation using nested loops followup