On Tue, Jul 7, 2015 at 10:59 AM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 07/07/2015 05:15 PM, Wes Vaske (wvaske) wrote: > >> 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. >> > > Wow, I would be pretty angry if I installed a SSD in my desktop, and it > loses a file that I saved just before pulling the power plug. > That can (and does) happen with spinning disks, too. > > *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. >> > > So it lies about fsync()... The next question is, does it nevertheless > enforce the correct ordering of persisting fsync'd data? If you write to > file A and fsync it, then write to another file B and fsync it too, is it > guaranteed that if B is persisted, A is as well? Because if it isn't, you > can end up with filesystem (or database) corruption anyway. > > - Heikki > > The sad fact is that MANY drives (ssd as well as spinning) lie about their fsync status. -- Mike Nolan
