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

From: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
To: toby <toby(at)telegraphics(dot)com(dot)au>
Cc: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
Subject: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
Date: 2006-11-10 18:54:01
Message-ID: 4554CAC9.3000104@cheapcomplexdevices.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

toby wrote:
>
> 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 know many _drivers_ lie about flushing - for example EXT3
on Linux before early 2005 "did not have write barrier support
that issues the FLUSH CACHE (IDE) or SYNCHRONIZE CACHE (SCSI)
commands even on fsync" according to the writer of
the Linux SATA driver.[1]

This has the same effect of having a lying disk drive to
any application code (including those designed to test for
lying drives), but is instead merely a software bug.

Does anyone have an example of an current (on the market so
I can get one) drive that lies about sync? I'd be interested
in getting my hands on one to see if it's a OS-software or
a drive-hw/firmware issue.

[1] http://hardware.slashdot.org/comments.pl?sid=149349&cid=12519114

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-11-10 23:55:51 Re: BUG #2737: hash indexing large table fails, while btree of same index works
Previous Message Abhijit Menon-Sen 2006-11-10 07:07:00 Re: 10x rowcount mis-estimation favouring merge over nestloop