From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from plane.gmane.org ([80.91.229.3]:36853 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751469Ab3LKOHm (ORCPT ); Wed, 11 Dec 2013 09:07:42 -0500 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VqkRx-0004qN-BK for linux-btrfs@vger.kernel.org; Wed, 11 Dec 2013 15:07:41 +0100 Received: from cpc21-stap10-2-0-cust974.12-2.cable.virginm.net ([86.0.163.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Dec 2013 15:07:41 +0100 Received: from m_btrfs by cpc21-stap10-2-0-cust974.12-2.cable.virginm.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Dec 2013 15:07:41 +0100 To: linux-btrfs@vger.kernel.org From: Martin Subject: Re: Feature Req: "mkfs.btrfs -d dup" option on single device Date: Wed, 11 Dec 2013 14:07:30 +0000 Message-ID: References: <01BDC0F3-CD4E-4BF1-898C-92AD50B66B41@colorremedies.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 In-Reply-To: Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 11/12/13 03:19, Imran Geriskovan wrote: SSDs: > What's more (in relation to our long term data integrity aim) > order of magnitude for their unpowered data retension period is > 1 YEAR. (Read it as 6months to 2-3 years. While powered they > refresh/shuffle the blocks) This makes SSDs > unsuitable for mid-to-long tem consumer storage. Hence they are > out of this discussion. (By the way, the only way for reliable > duplication on SSDs, is using physically seperate devices.) Interesting... Have you any links/quotes/studies/specs for that please? Does btrfs need to date-stamp each block/chunk to ensure that data is rewritten before suffering flash memory bitrot? Is not the firmware in SSDs aware to rewrite any too-long unchanged data? Regards, Martin