| From: | david(at)lang(dot)hm |
|---|---|
| To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
| Cc: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: SSD + RAID |
| Date: | 2010-02-23 21:22:16 |
| Message-ID: | alpine.DEB.2.00.1002231256470.5131@asgard.lang.hm |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 23 Feb 2010, Aidan Van Dyk wrote:
> * david(at)lang(dot)hm <david(at)lang(dot)hm> [100223 15:05]:
>
>> However, one thing that you do not get protection against with software
>> raid is the potential for the writes to hit some drives but not others.
>> If this happens the software raid cannot know what the correct contents
>> of the raid stripe are, and so you could loose everything in that stripe
>> (including contents of other files that are not being modified that
>> happened to be in the wrong place on the array)
>
> That's for stripe-based raid. Mirror sets like raid-1 should give you
> either the old data, or the new data, both acceptable responses since
> the fsync/barreir hasn't "completed".
>
> Or have I missed another subtle interaction?
one problem is that when the system comes back up and attempts to check
the raid array, it is not going to know which drive has valid data. I
don't know exactly what it does in that situation, but this type of error
in other conditions causes the system to take the array offline.
David Lang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kevin Grittner | 2010-02-23 21:23:54 | Re: moving pg_xlog -- yeah, it's worth it! |
| Previous Message | Aidan Van Dyk | 2010-02-23 20:34:35 | Re: SSD + RAID |