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

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 (view raw or flat)
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

pgsql-performance by date

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

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