Re: SSD + RAID

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
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 09:34:42
Message-ID: 6EE5C3AE-2F84-4C8C-AC3E-D76293117352@richrelevance.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

> --
> 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. +
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2010-02-21 14:10:43 Re: SSD + RAID
Previous Message terry 2010-02-21 05:44:57 Re: can we optimize STACK_DEPTH_SLOP