Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1ZCUOr-00089h-0B for pgsql-performance@arkaria.postgresql.org; Tue, 07 Jul 2015 15:03:09 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1ZCUOq-00071w-Bp for pgsql-performance@arkaria.postgresql.org; Tue, 07 Jul 2015 15:03:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1ZCULk-00053O-No for pgsql-performance@postgresql.org; Tue, 07 Jul 2015 14:59:56 +0000 Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1ZCULh-00048J-7x for pgsql-performance@postgresql.org; Tue, 07 Jul 2015 14:59:56 +0000 Received: by wgfr2 with SMTP id r2so15584154wgf.1 for ; Tue, 07 Jul 2015 07:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3wITYLpMXBJLBkGPQR8yV9u76LJaXHXf+reQbsBMqqs=; b=fqJTm2MlPz9eG2LtdF63Ss89bzU/cHnv1G/RnlvV9246dJ/9zy+bvFr4TvSq011tah i1OLDEf6RU0dqERiiDlNBKtNxRYU9SJrIfdgfYPVpcGKvFL1v6iWNVpsc4j9GUXRgt3G KTjzRIdAew3C718GBnhqh++5BgRqgkLXsgsZkcPUh1GEPLxClbaerfSyd3Q2gipZoKFt gzj42pd1GTmi3HyR1FqezrST/wI3NJr/BsFN5ToAlVrExWXiu1WvO/yQzL8utwXasbzA dHkEPf3pP3CDwzPwSfrBXw4hVndtWI26WAf1t0VP98t1aPdfHxVqef1R0f5vBfm6IwcE tefA== X-Received: by 10.180.75.4 with SMTP id y4mr64280989wiv.1.1436281192567; Tue, 07 Jul 2015 07:59:52 -0700 (PDT) Received: from [192.168.1.110] (dsl-hkibrasgw1-58c38f-82.dhcp.inet.fi. [88.195.143.82]) by mx.google.com with ESMTPSA id fq7sm52879527wic.5.2015.07.07.07.59.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 07:59:52 -0700 (PDT) Message-ID: <559BE965.7090609@iki.fi> Date: Tue, 07 Jul 2015 17:59:49 +0300 From: Heikki Linnakangas Reply-To: hlinnaka@iki.fi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: "Wes Vaske (wvaske)" , "Graeme B. Bell" , "pgsql-performance@postgresql.org" Subject: Re: New server: SSD/RAID recommendations? References: <31701C89A44B714FB8D242F806E7286C5AED32FA@NTXBOIMBX01.micron.com> <31701C89A44B714FB8D242F806E7286C5AED33EB@NTXBOIMBX01.micron.com> <31701C89A44B714FB8D242F806E7286C5AED372E@NTXBOIMBX01.micron.com> In-Reply-To: <31701C89A44B714FB8D242F806E7286C5AED372E@NTXBOIMBX01.micron.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.4 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org 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. > *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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance