| From: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
|---|---|
| To: | carlosreimer(at)terra(dot)com(dot)br |
| Cc: | Mark Lewis <mark(dot)lewis(at)mir3(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: RES: Initial database loading and IDE x SCSI |
| Date: | 2006-06-03 00:13:27 |
| Message-ID: | 4480D427.50207@paradise.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Mark Lewis wrote:
>
> The naive approach works on IDE drives because they don't (usually)
> honor the request to write the data immediately, so it can fill its
> write cache up with several megabytes of data and write it out to the
> disk at its leisure.
>
FWIW - If you are using MacOS X or Windows, then later SATA (in
particular, not sure about older IDE) will honor the request to write
immediately, even if the disk write cache is enabled.
I believe that Linux 2.6+ and SATA II will also behave this way (I'm
thinking that write barrier support *is* in 2.6 now - however you would
be wise to follow up on the Linux kernel list if you want to be sure!)
In these cases data integrity becomes similar to SCSI - however, unless
you buy SATA specifically designed for a server type workload (e.g WD
Raptor), then ATA/SATA tend to fail more quickly if used in this way
(e.g. 24/7, hot/dusty environment etc).
Cheers
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | fzied | 2006-06-03 09:31:03 | scaling up postgres |
| Previous Message | carlosreimer | 2006-06-02 20:55:38 | RES: RES: RES: Initial database loading and IDE x SCSI |