Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?] - Mailing list pgsql-performance

From Ron Mayer
Subject Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]
Date
Msg-id 4554CAC9.3000104@cheapcomplexdevices.com
Whole thread Raw
Responses Re: Lying drives [Was: Re: Which OS provides the _fastest_ PostgreSQL performance?]  (Guy Thornley <guy@esphion.com>)
List 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

pgsql-performance by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: 10x rowcount mis-estimation favouring merge over nestloop
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #2737: hash indexing large table fails, while btree of same index works