Re: SSD + RAID - Mailing list pgsql-performance

From david@lang.hm
Subject Re: SSD + RAID
Date
Msg-id alpine.DEB.2.00.1002231131300.5131@asgard.lang.hm
Whole thread Raw
In response to Re: SSD + RAID  (david@lang.hm)
Responses Re: SSD + RAID  (Aidan Van Dyk <aidan@highrise.ca>)
List pgsql-performance
On Tue, 23 Feb 2010, david@lang.hm wrote:

> On Mon, 22 Feb 2010, Ron Mayer wrote:
>
>>
>> Also worth noting - Linux's software raid stuff (MD and LVM)
>> need to handle this right as well - and last I checked (sometime
>> last year) the default setups didn't.
>>
>
> I think I saw some stuff in the last few months on this issue on the kernel
> mailing list. you may want to doublecheck this when 2.6.33 gets released
> (probably this week)

to clarify further (after getting more sleep ;-)

I believe that the linux software raid always did the right thing if you
did a fsync/fdatacync. however barriers that filesystems attempted to use
to avoid the need for a hard fsync used to be silently ignored. I believe
these are now honored (in at least some configurations)

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)

If you have critical data, you _really_ want to use a raid controller with
battery backup so that if you loose power you have a chance of eventually
completing the write.

David Lang

pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Internal operations when the planner makes a hash join.
Next
From: Aidan Van Dyk
Date:
Subject: Re: SSD + RAID