[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: [ADMIN] hanging for 30sec when checkpointing
From:       "scott.marlowe" <scott.marlowe () ihs ! com>
Date:       2004-02-09 16:58:34
Message-ID: Pine.LNX.4.33.0402090956580.23974-100000 () css120 ! ihs ! com
[Download RAW message or body]

On Sat, 7 Feb 2004, Peter Galbavy wrote:

> scott.marlowe wrote:
> > Also, running on SCSI drives will be much faster than running on IDE
> > drives if the IDE drives have their caches disabled like they should,
> > since they lie otherwise.  Since SCSI disks don't usually lie, and are
> > designed to handle multiple requests in parallel, they are much
> > faster as parallel load increases.  If you're writing a lot, you
> > should either have a great number of IDE drives with the write cache
> > turned off, like some of the newer storage devices made of ~100 IDE
> > drives, or you should have SCSI.  SCSI's advantage won't be as great
> > as the number of drives approaches infinity.  But for 1 to 10 drives
> > my guess is that SCSI is gonna be a clear winner under parallel load.
> 
> Nice to see old fashioned misinformation being spread around the place...

I don't know who you think you are, but I've physically tested the stuff 
I'm talking about.  Care to qualify what you mean?

IDE drives (all the ones I've ever tested) LIE about their write caches 
and fsync.  don't believe me?  Simple, hook one up, initiate 100 parallel 
transactions, pull the power plug, watch your database fail to come back 
up due to the corruption caused by the LYING IDE drives.

Do the same with SCSI.  watch the database come right back to life.

If you're gonna accuse me of lying, you damned well better have the balls 
AND evidence to back it up.


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
[prev in list] [next in list] [prev in thread] [next in thread]