Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 3076C633C6D for ; Mon, 22 Feb 2010 01:39:21 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 64354-08 for ; Mon, 22 Feb 2010 05:39:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mail.postgresql.org (Postfix) with ESMTP id 7AF0B633C63 for ; Mon, 22 Feb 2010 01:39:10 -0400 (AST) Received: from [192.168.1.3] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LlrG8-1NANJ52PD6-00ZqAU; Mon, 22 Feb 2010 06:39:09 +0100 Message-ID: <4B82187A.7060604@2ndquadrant.com> Date: Mon, 22 Feb 2010 00:39:06 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ron Mayer CC: Bruce Momjian , pgsql-performance Subject: Re: SSD + RAID References: <201002211410.o1LEAht05941@momjian.us> <4B814920.1040204@cheapcomplexdevices.com> In-Reply-To: <4B814920.1040204@cheapcomplexdevices.com> Content-Type: multipart/alternative; boundary="------------000202010002080200090600" X-Provags-ID: V01U2FsdGVkX1/q3HdlCqGD0vyeiiDGGdVpxwhRNjCypbYQmFj xmXw8aXa+BoO5IgQtVU49GlpgUoAMDHhgXoXBkDmzbAUalD23Y DbJDuItVCiR2eN6xDrBrQkkGmqeVdSA X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201002/292 X-Sequence-Number: 37713 This is a multi-part message in MIME format. --------------000202010002080200090600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ron Mayer wrote: > Bruce Momjian wrote: > >> Agreed, thought I thought the problem was that SSDs lie about their >> cache flush like SATA drives do, or is there something I am missing? >> > > There's exactly one case I can find[1] where this century's IDE > drives lied more than any other drive with a cache: Ron is correct that the problem of mainstream SATA drives accepting the cache flush command but not actually doing anything with it is long gone at this point. If you have a regular SATA drive, it almost certainly supports proper cache flushing. And if your whole software/storage stacks understands all that, you should not end up with corrupted data just because there's a volative write cache in there. 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). This whole area remains a disaster area and extreme distrust of all the SSD storage vendors is advisable at this point. Basically, if I don't see the capacitor responsible for flushing outstanding writes, and get a clear description from the manufacturer how the cached writes are going to be handled in the event of a power failure, at this point I have to assume the answer is "badly and your data will be eaten". And the prices for SSDs that meet that requirement are still quite steep. I keep hoping somebody will address this market at something lower than the standard "enterprise" prices. The upcoming SandForce designs seem to have thought this through correctly: http://www.anandtech.com/storage/showdoc.aspx?i=3702&p=6 But the product's not out to the general public yet (just like the Seagate units that claim to have capacitor backups--I heard a rumor those are also Sandforce designs actually, so they may be the only ones doing this right and aiming at a lower price). -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us --------------000202010002080200090600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ron Mayer wrote: 
Bruce Momjian wrote:
  
Agreed, thought I thought the problem was that SSDs lie about their
cache flush like SATA drives do, or is there something I am missing?
    

There's exactly one case I can find[1] where this century's IDE
drives lied more than any other drive with a cache:

Ron is correct that the problem of mainstream SATA drives accepting the cache flush command but not actually doing anything with it is long gone at this point.  If you have a regular SATA drive, it almost certainly supports proper cache flushing.  And if your whole software/storage stacks understands all that, you should not end up with corrupted data just because there's a volative write cache in there.

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

This whole area remains a disaster area and extreme distrust of all the SSD storage vendors is advisable at this point.  Basically, if I don't see the capacitor responsible for flushing outstanding writes, and get a clear description from the manufacturer how the cached writes are going to be handled in the event of a power failure, at this point I have to assume the answer is "badly and your data will be eaten".  And the prices for SSDs that meet that requirement are still quite steep.  I keep hoping somebody will address this market at something lower than the standard "enterprise" prices.  The upcoming SandForce designs seem to have thought this through correctly:  http://www.anandtech.com/storage/showdoc.aspx?i=3702&p=6  But the product's not out to the general public yet (just like the Seagate units that claim to have capacitor backups--I heard a rumor those are also Sandforce designs actually, so they may be the only ones doing this right and aiming at a lower price).

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us
--------------000202010002080200090600--