Skip site navigation (1) Skip section navigation (2)


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: (view raw, whole thread or download thread mbox)
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 
> 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:  
>  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

  Bruce Momjian  <bruce(at)momjian(dot)us>
  PG East:
  + If your life is a hard drive, Christ can be your backup. +

Attachment: /rtmp/diff
Description: text/x-diff (1.6 KB)

In response to


pgsql-performance by date

Next:From: Greg SmithDate: 2010-02-27 19:38:20
Subject: Re: SSD + RAID
Previous:From: Tory M BlueDate: 2010-02-26 23:24:42
Subject: Re: bgwriter, checkpoints, curious (seeing delays)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group