I'm not an expert on which and where -- its been a while since I was exposed to the issue. From what I've read in a few places over time (storagereview.com, linux and windows patches or knowledge base articles), it happens from time to time. Drives usually get firmware updates quickly. Drivers / Controller cards often take longer to fix. Anyway, my anecdotal recollection was with a few instances of this occuring about 4 years ago and manefesting itself with complaints on message boards then going away. And in general some searching around google indicates this is a problem more often drivers and controllers than drives themselves.
I recall some cheap raid cards and controller cards being an issue, like the below:
http://www.fixya.com/support/t163682-hard_drive_corrupt_every_reboot
And here is an example of an HP Fiber Channel Disk firmware bug:
HS02969 28SEP07
•
Title
: OPN FIBRE CHANNEL DISK FIRMWARE
•
Platform
: S-Series & NS-Series only with FCDMs
•
Summary
:
HP recently discovered a firmware flaw in some versions of 72,
146, and 300 Gigabyte fibre channel disk devices that shipped in late 2006
and early 2007. The flaw enabled the affected disk devices to inadvertently
cache write data. In very rare instances, this caching operation presents an
opportunity for disk write operations to be lost.
Even ext3 doesn't default to using write barriers at this time due to performance concerns:
http://lwn.net/Articles/283161/
I recall some cheap raid cards and controller cards being an issue, like the below:
http://www.fixya.com/support/t163682-hard_drive_corrupt_every_reboot
And here is an example of an HP Fiber Channel Disk firmware bug:
HS02969 28SEP07
•
Title
: OPN FIBRE CHANNEL DISK FIRMWARE
•
Platform
: S-Series & NS-Series only with FCDMs
•
Summary
:
HP recently discovered a firmware flaw in some versions of 72,
146, and 300 Gigabyte fibre channel disk devices that shipped in late 2006
and early 2007. The flaw enabled the affected disk devices to inadvertently
cache write data. In very rare instances, this caching operation presents an
opportunity for disk write operations to be lost.
Even ext3 doesn't default to using write barriers at this time due to performance concerns:
http://lwn.net/Articles/283161/
On Tue, Aug 12, 2008 at 6:33 PM, <david@xxxxxxx> wrote:
On Tue, 12 Aug 2008, Ron Mayer wrote:I can't name one, but I've seen it mentioned in the discussions on linux-kernel several times by the folks who are writing the write-barrier support.
Scott Carey wrote:
Some SATA drives were known to not flush their cache when told to.
Can you name one? The ATA commands seem pretty clear on the matter,
and ISTM most of the reports of these issues came from before
Linux had write-barrier support.
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
