From: Bruce Momjian <bruce@momjian.us>
To: Scott Carey <scott@richrelevance.com>
Cc: Dan Langille <dan@langille.org>
Cc: Matthew Wakeling <matthew@flymine.org>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Laszlo Nagy <gandalf@shopzeus.com>
Cc: pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: SSD + RAID
Date: Sun, 21 Feb 2010 09:10:43 -0500 (EST)
Message-ID: <201002211410.o1LEAht05941@momjian.us> (raw)
In-Reply-To: <6EE5C3AE-2F84-4C8C-AC3E-D76293117352@richrelevance.com>
Scott Carey wrote:
> On Feb 20, 2010, at 3:19 PM, Bruce Momjian wrote:
>
> > Dan Langille wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> 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.
> >>>>
> >>>> http://www.theregister.co.uk/2009/12/08/seagate_pulsar_ssd/
> >>>
> >>> 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@momjian.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. +
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bruce@momjian.us, scott@richrelevance.com, dan@langille.org, matthew@flymine.org, greg@2ndquadrant.com, gandalf@shopzeus.com
Subject: Re: SSD + RAID
In-Reply-To: <201002211410.o1LEAht05941@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox