Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]

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.

In response to

Responses

Browse pgsql-performance by date

  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