The M500/M550/M600 are consumer class drives that don't have power protection for all inflight data.* (like the Samsung 8x0 series and the Intel 3x0 & 5x0 series).
The M500DC has full power protection for inflight data and is an enterprise-class drive (like the Samsung 845DC or Intel S3500 & S3700 series). So any drive without the capacitors to protect inflight data will suffer from data loss if you're using disk write cache and you pull the power. *Big addendum: There are two issues on powerloss that will mess with Postgres. Data Loss and Data Corruption. The micron consumer drives will have power loss protection against Data Corruption and the enterprise drive will have power loss protection against BOTH. https://www.micron.com/~/media/documents/products/white-paper/wp_ssd_power_loss_protection.pdf The Data Corruption problem is only an issue in non-SLC NAND but it's industry wide. And even though some drives will protect against that, the protection of inflight data that's been fsync'd is more important and should disqualify *any* consumer drives from *any* company from consideration for use with Postgres. Wes Vaske | Senior Storage Solutions Engineer Micron Technology -----Original Message----- From: Graeme B. Bell [mailto:graeme.b...@nibio.no] Sent: Tuesday, July 07, 2015 8:26 AM To: Merlin Moncure Cc: Wes Vaske (wvaske); Craig James; pgsql-performance@postgresql.org Subject: Re: [PERFORM] New server: SSD/RAID recommendations? As I have warned elsewhere, The M500/M550 from $SOME_COMPANY is NOT SUITABLE for postgres unless you have a RAID controller with BBU to protect yourself. The M500/M550 are NOT plug-pull safe despite the 'power loss protection' claimed on the packaging. Not all fsync'd data is preserved in the event of a power loss, which completely undermines postgres's sanity. I would be extremely skeptical about the M500DC given the name and manufacturer. I went to quite a lot of trouble to provide $SOME_COMPANYs engineers with the full details of this fault after extensive testing (we have e.g. 20-25 of these disks) on multiple machines and controllers, at their request. Result: they stopped replying to me, and soon after I saw their PR reps talking about how 'power loss protection isn't about protecting all data during a power loss'. The only safe way to use an M500/M550 with postgres is: a) disable the disk cache, which will cripple performance to about 3-5% of normal. b) use a battery backed or cap-backed RAID controller, which will generally hurt performance, by limiting you to the peak performance of the flash on the raid controller. If you are buying such a drive, I strongly recommend buying only one and doing extensive plug pull testing before commiting to several. For myself, my time is valuable enough that it will be cheaper to buy intel in future. Graeme. On 07 Jul 2015, at 15:12, Merlin Moncure <mmonc...@gmail.com> wrote: > On Thu, Jul 2, 2015 at 1:00 PM, Wes Vaske (wvaske) <wva...@micron.com> wrote: > Storage Review has a pretty good process and reviewed the M500DC when it > released last year. > http://www.storagereview.com/micron_m500dc_enterprise_ssd_review > > > > The only database-specific info we have available are for Cassandra and MSSQL: > > http://www.micron.com/~/media/documents/products/technical-marketing-brief/cassandra_and_m500dc_enterprise_ssd_tech_brief.pdf > > http://www.micron.com/~/media/documents/products/technical-marketing-brief/sql_server_2014_and_m500dc_raid_configuration_tech_brief.pdf > > > > (some of that info might be relevant) > > > > In terms of endurance, the M500DC is rated to 2 Drive Writes Per Day (DWPD) > for 5-years. For comparison: > > Micron M500DC (20nm) - 2 DWPD > > Intel S3500 (20nm) - 0.3 DWPD > > Intel S3510 (16nm) - 0.3 DWPD > > Intel S3710 (20nm) - 10 DWPD > > > > They're all great drives, the question is how write-intensive is the workload. > > > > > Intel added a new product, the 3610, that is rated for 3 DWPD. Pricing looks > to be around 1.20$/GB. > > merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance