Re: SSD + RAID

Поиск
Список
Период
Сортировка
От david@lang.hm
Тема Re: SSD + RAID
Дата
Msg-id alpine.DEB.2.00.1002231131300.5131@asgard.lang.hm
обсуждение исходный текст
Ответ на Re: SSD + RAID  (david@lang.hm)
Ответы Re: SSD + RAID  (Aidan Van Dyk <aidan@highrise.ca>)
Список 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 по дате отправления:

Предыдущее
От: Scott Carey
Дата:
Сообщение: Re: Internal operations when the planner makes a hash join.
Следующее
От: Aidan Van Dyk
Дата:
Сообщение: Re: SSD + RAID