From: | Guy Thornley <guy(at)esphion(dot)com> |
---|---|
To: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
Cc: | toby <toby(at)telegraphics(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] |
Date: | 2006-11-13 08:32:05 |
Message-ID: | 20061113083205.GJ29915@esphion.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> > That's not quite what I meant by "trust". Some drives lie about the
> > flush.
>
> Is that really true, or a misdiagnosed software bug?
I've yet to find a drive that lies about write completion. (*)
The problem is that the drives boot-up default is write-caching enabled (or
perhaps the system BIOS sets it that way).
If you turn an IDE disks write cache off explicity, using hdparm or similar,
they behave.
The problem, I think, is a bug in hdparm or the linux kernel: if you use the
little-'i' option, the output indicates the WC is disabled. However, if you
use big-'I' to actually interrogate the drive, you get the correct setting.
I tested this a while ago by writing a program that did fsync() to test
write latency and random-reads to test read latency, and then comparing
them.
- Guy
* I did experience a too-close-to-call case, where after write-cache was
disabled, the write latency was the same as the read latency. For every
other drive the write latency much, MUCH higher. However, before I
disabled the WC, the write latency was a fraction of the read latency.
From | Date | Subject | |
---|---|---|---|
Next Message | Cosimo Streppone | 2006-11-14 09:51:44 | Re: Context switch storm |
Previous Message | Simon Riggs | 2006-11-11 08:17:54 | Re: [PERFORM] BUG #2737: hash indexing large table fails, while btree of same index works |