Re: SSD + RAID - Mailing list pgsql-performance

From Scott Carey
Subject Re: SSD + RAID
Date
Msg-id 6EE5C3AE-2F84-4C8C-AC3E-D76293117352@richrelevance.com
Whole thread Raw
In response to Re: SSD + RAID  (Bruce Momjian <bruce@momjian.us>)
Responses Re: SSD + RAID  (Bruce Momjian <bruce@momjian.us>)
List 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.
Itwill flush data in 'transaction groups' and flush the drive write caches at the end of those transactions.  Since its
copyon write, it can ensure that all the changes in the transaction group appear on disk, or all are lost.  This all
worksso long as the cache flush commands do. 


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


pgsql-performance by date:

Previous
From: "terry"
Date:
Subject: Re: can we optimize STACK_DEPTH_SLOP
Next
From: Bruce Momjian
Date:
Subject: Re: SSD + RAID