| From: | Bruce Momjian <bruce(at)momjian(dot)us> | 
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> | 
| Cc: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | Re: SSD + RAID | 
| Date: | 2010-02-27 01:40:18 | 
| Message-ID: | 201002270140.o1R1eIm24724@momjian.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
I have added documentation about the ATAPI drive flush command, and the
typical SSD behavior.
---------------------------------------------------------------------------
Greg Smith wrote:
> 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(at)2ndQuadrant(dot)com   www.2ndQuadrant.us
> 
-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
  PG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do
  + If your life is a hard drive, Christ can be your backup. +
| Attachment | Content-Type | Size | 
|---|---|---|
| /rtmp/diff | text/x-diff | 1.6 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2010-02-27 19:38:20 | Re: SSD + RAID | 
| Previous Message | Tory M Blue | 2010-02-26 23:24:42 | Re: bgwriter, checkpoints, curious (seeing delays) |