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
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 |