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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance