I always assumed SCSI disks had a write-through cache and therefore
didn't need a drive cache flush comment.
Maximum performance can only be reached with a writeback cache so the
drive can reorder and cluster writes, according to the realtime position
of the heads and platter rotation.
The problem is not the write cache itself, it is that, for your data to be
safe, the "flush cache" or "barrier" command must get all the way through
the application / filesystem to the hardware, going through a nondescript
number of software/firmware/hardware layers, all of which may :
- not specify if they honor or ignore flush/barrier commands, and which
ones
- not specify if they will reordre writes ignoring barriers/flushes or not
- have been written by people who are not aware of such issues
- have been written by companies who are perfectly aware of such issues
but chose to ignore them to look good in benchmarks
- have some incompatibilities that result in broken behaviour
- have bugs
As far as I'm concerned, a configuration that doesn't properly respect the
commands needed for data integrity is broken.
The sad truth is that given a software/hardware IO stack, there's no way
to be sure, and testing isn't easy, if at all possible to do. Some cache
flushes might be ignored under some circumstances.
For this to change, you don't need a hardware change, but a mentality
change.
Flash filesystem developers use flash simulators which measure wear
leveling, etc.
We'd need a virtual box with a simulated virtual harddrive which is able
to check this.
What a mess.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
