On Mon, 9 Feb 2004, Goulet, Dick wrote:
> Scott,
>
> If you feel it is necessary to apologize for such a minor
> infraction of polite etiquette please come on over to Oracle-L. We have
> harshness 10 times greater. Probably because there are so many
> practioners and so many different points of view. We call them "Holy
> Wars". The current blazing one is on RAID, the good, the bad, and the
> ugly.
Hehe, I grew up on FIDO net, so I know all about the flammage... :-)
I can still remember the amiga versus atari ST holy wars of old.
> BTW: From a Holy War on Oracle-L of similar topic. There is a
> difference on how bad that lying IDE drive is depending on who the
> vendor is, what system it's plugged into, and what OS is being used.
> Some do a better job than others of "covering up" the lies. The other
> chap may have one of those better systems, so from his point of view
> it's "old fashioned misinformation". Doesn't mean it's not true, just
> covered up better. Kind of like "Air Freshener".
Well, it's interesting that during all the testing I and many others were
doing last year, it appeared the escalade IDE RAID controllers were doing
SOMETHING (no is quite sure if it was disabling write cache or not, but we
guessed that was so) that made the IDE drives under them safe from the
power off data loss issue that IDE drives seem to suffer from.
As for the OS, my guess is that some OSes probably just insert some delay
between receiving an fsync notification from an IDE drive and reporting it
back to the application or something like that, that makes them appear
safe. Such situations often result in systems that only fail under very
heavy concurrent load, but pass the test under light to medium
concurrency.
That said we have a really HUGE (~200 drive) IDE storage array my web /
app server sits on top of. No clue if that thing will reliably work under
a database, and I'm in no hurry to find out.
But since the fsync on WAL is all that seems important, I could always
initlocation a big chunk of it and keep the WAL local and I should be ok.