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


From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Dan Langille <dan(at)langille(dot)org>, Matthew Wakeling <matthew(at)flymine(dot)org>, Greg Smith <greg(at)2ndquadrant(dot)com>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2010-02-21 14:10:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Scott Carey wrote:
> On Feb 20, 2010, at 3:19 PM, Bruce Momjian wrote:
> > Dan Langille wrote:
> >> Hash: SHA1
> >>
> >> Bruce Momjian wrote:
> >>> Matthew Wakeling wrote:
> >>>> On Fri, 13 Nov 2009, 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.
> >>>> Seagate are claiming to be on the ball with this one.
> >>>>
> >>>>
> >>>
> >>> I have updated our documentation to mention that even SSD drives often
> >>> have volatile write-back caches.  Patch attached and applied.
> >>
> >> Hmmm.  That got me thinking: consider ZFS and HDD with volatile cache.
> >> Do the characteristics of ZFS avoid this issue entirely?
> >
> > No, I don't think so.  ZFS only avoids partial page writes.  ZFS still
> > assumes something sent to the drive is permanent or it would have no way
> > to operate.
> >
> ZFS is write-back cache aware, and safe provided the drive's
> cache flushing and write barrier related commands work.  It will
> flush data in 'transaction groups' and flush the drive write
> caches at the end of those transactions.  Since its copy on
> write, it can ensure that all the changes in the transaction
> group appear on disk, or all are lost.  This all works so long
> as the cache flush commands do.

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?

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

In response to


pgsql-performance by date

Next:From: Ron MayerDate: 2010-02-21 14:54:24
Subject: Re: SSD + RAID
Previous:From: Scott CareyDate: 2010-02-21 09:34:42
Subject: Re: SSD + RAID

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