On 22-2-2010 6:39 Greg Smith wrote:
But the point of this whole testing exercise coming back into vogue
again is that SSDs have returned this negligent behavior to the
mainstream again. See
http://opensolaris.org/jive/thread.jspa?threadID=121424 for a discussion
of this in a ZFS context just last month. There are many documented
cases of Intel SSDs that will fake a cache flush, such that the only way
to get good reliable writes is to totally disable their writes
caches--at which point performance is so bad you might as well have
gotten a RAID10 setup instead (and longevity is toast too).
That's weird. Intel's SSD's didn't have a write cache afaik:
"I asked Intel about this and it turns out that the DRAM on the Intel
drive isn't used for user data because of the risk of data loss, instead
it is used as memory by the Intel SATA/flash controller for deciding
exactly where to write data (I'm assuming for the wear
leveling/reliability algorithms)."
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3403&p=10
But that is the old version, perhaps the second generation does have a
bit of write caching.
I can understand a SSD might do unexpected things when it loses power
all of a sudden. It will probably try to group writes to fill a single
block (and those blocks vary in size but are normally way larger than
those of a normal spinning disk, they are values like 256 or 512KB) and
it might loose that "waiting until a full block can be written"-data or
perhaps it just couldn't complete a full block-write due to the power
failure.
Although that behavior isn't really what you want, it would be incorrect
to blame write caching for the behavior if the device doesn't even have
a write cache ;)
Best regards,
Arjen
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
