Re: ATA disks and RAID controllers for database servers - Mailing list pgsql-general

From Christopher Browne
Subject Re: ATA disks and RAID controllers for database servers
Date
Msg-id m3ptfth8w1.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to ATA disks and RAID controllers for database servers  (Mark Kirkwood <markir@paradise.net.nz>)
Responses Re: ATA disks and RAID controllers for database servers
List pgsql-general
Clinging to sanity, threshar@torgo.978.org (Jeff) mumbled into her beard:
> On Sat, 15 Nov 2003 14:07:40 +1300
> Mark Kirkwood <markir@paradise.net.nz> wrote:
>>
>> Clearly it is possible to obtain very good performance with write
>> caching on using RAID0, and if you have a UPS together with good backup
>> practice then this could be the way to go.
>>
>> With caching off there is a considerable decrease in performance,
>> however this performance may be "good enough" if viewed in a
>> cost-benefit-safely manner.
>
> UNless the controller itself has a battery backed cache it is
> dangerous - there are many more failures than losing power.  Ie,
> blowing out the power supply or cpu.  We've burnt up a fair share of
> cpu's over the years.  Luckly on a Sun it isn't that big a
> deal.. but on x86. wel... you get the idea.

Furthermore, if the disk drives are lying to the controller, it's
anybody's guess whether or not data ever actually gets to the disk.

When is it safe to let blocks expire out of the controller cache?

If your computer can't know if the data has been written (because of
drives that lie), I can't imagine how the controller would (since the
drives are lying to the controller, too).
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www3.sympatico.ca/cbbrowne/
"The  primary  difference  between  computer  salesmen  and  used  car
salesmen is that used car salesmen know when they're lying to you."

pgsql-general by date:

Previous
From: Lynn.Tilby@asu.edu
Date:
Subject: Re: Updated Documentation
Next
From: Christopher Browne
Date:
Subject: Re: embedded postgresql