Greg Smith wrote:
> In order for a drive to work reliably for database use such as for
> PostgreSQL, it cannot have a volatile write cache. You either need a
> write cache with a battery backup (and a UPS doesn't count), or to
> turn the cache off. The SSD performance figures you've been looking
> at are with the drive's write cache turned on, which means they're
> completely fictitious and exaggerated upwards for your purposes. In
> the real world, that will result in database corruption after a crash
> one day.
If power is "unexpectedly" removed from the system, this is true. But
the caches on the SSD controllers are BUFFERS. An operating system
crash does not disrupt the data in them or cause corruption. An
unexpected disconnection of the power source from the drive (due to
unplugging it or a power supply failure for whatever reason) is a
different matter.
> No one on the drive benchmarking side of the industry seems to have
> picked up on this, so you can't use any of those figures. I'm not
> even sure right now whether drives like Intel's will even meet their
> lifetime expectations if they aren't allowed to use their internal
> volatile write cache.
>
> Here's two links you should read and then reconsider your whole design:
> http://www.mysqlperformanceblog.com/2009/03/02/ssd-xfs-lvm-fsync-write-cache-barrier-and-lost-transactions/
>
> http://petereisentraut.blogspot.com/2009/07/solid-state-drive-benchmarks-and-write.html
>
>
> I can't even imagine how bad the situation would be if you decide to
> wander down the "use a bunch of really cheap SSD drives" path; these
> things are barely usable for databases with Intel's hardware. The
> needs of people who want to throw SSD in a laptop and those of the
> enterprise database market are really different, and if you believe
> doom forecasting like the comments at
> http://blogs.sun.com/BestPerf/entry/oracle_peoplesoft_payroll_sun_sparc
> that gap is widening, not shrinking.
Again, it depends.
With the write cache off on these disks they still are huge wins for
very-heavy-read applications, which many are. The issue is (as always)
operation mix - if you do a lot of inserts and updates then you suffer,
but a lot of database applications are in the high 90%+ SELECTs both in
frequency and data flow volume. The lack of rotational and seek latency
in those applications is HUGE.
-- Karl Denninger