From owner-freebsd-arm@freebsd.org Wed Mar 23 06:32:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A81D1AD7BBD for ; Wed, 23 Mar 2016 06:32:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 781381439 for ; Wed, 23 Mar 2016 06:32:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id c63so20169167iof.0 for ; Tue, 22 Mar 2016 23:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=kPqt5OsJaWJC2UMutxlshIU3ZK58Dtju312aGiuCX5k=; b=AeOjO/sG0WWbCXh6vkObA4WGG3u9jQIF0zR6uiUmARupAsXCLv0yJWuuo+WYAWgpCq WwM9BVD3lRIppRwGWTqZ6zm8rfb//iCrGk9YKMq5cxY77goBlPyKbgtPHF6pz+KXeyq1 BeZO+38sf7LGz+nep2o0/p9bc9yuk8cSh7+p9fVf2+xoKd2F2TbI+Nqyt7X57gJZrGo1 sdd+2thpAQsjMXVOd06owAKk2z5AZyfQM10nigLgZvffE4tknLD7x6dLRiXLDMSly0N0 twxYHEVw+wZe0wSLRFVleGwMMxG4RQrZNu4vo0Q6RiFCCuH0MECwf5hKP3mQ/yVs79Sb dmuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kPqt5OsJaWJC2UMutxlshIU3ZK58Dtju312aGiuCX5k=; b=Hhtf51eKadYbToQ9R6O0i/yY/08IG9A8fmerqfcEc7sPPWGtTfGhmmsFTvxwUMEaOJ ThPyIcP0B0A/2rsZ4TWPaV/n7NJjdFAvuYez3Mrs29m4Y57I/d0hfPNflti9kJL7lbar OpN64uAik/L0+lfirgG9Jd9tPx6IrjktxCU2uciWuq9DF+/VcMDqW0pLyHuSALzDmtCf k9sJc8p80wNMAV2WQuAhamp/dHLb9oloj4AC5hX/LGpbVLflMUVpdwIiQJ1zMoYGQEx6 9b2t4PKUPKeLO0L2Enyx9RpTZC9xawyk3bf21iOhzmtAppgExWTyVbZ0rZEnpGuZYCAc ze2w== X-Gm-Message-State: AD7BkJJtsZhwuap0blZErfFFq/oe75ESeXQgs/GoaxMTWrZFxp8DrkKqQE77ArD6r/SOx3yVRI79OGttR1ji7g== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr1538941ioe.135.1458714750813; Tue, 22 Mar 2016 23:32:30 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:32:30 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> Date: Wed, 23 Mar 2016 00:32:30 -0600 X-Google-Sender-Auth: R8-2uE69UqGDXELFcVl6MZJZBdY Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Russell Haley Cc: bob prohaska , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:32:31 -0000 On Mon, Mar 21, 2016 at 10:39 PM, Russell Haley wrote: > How long can nand go without power before it starts to lose data integrity? > It depends on the NAND. Most NAND is spec'd for 1 of 3 common values: 1 month, 3 months or 1 year. This spec is the 'end of life' spec, and always at 40C. When the NAND is worn out, it will still be readable after it has been off for this period of time. Temperature does have a lot to do with it. At 0C, NAND can last up to 80 times longer, in theory. Likewise, at 70C, it will age 80 times faster. It's generally an Arrhenius relationship between temperature and data retention. The hotter the nand, the less long data lasts, though the faster the program and erase times (and the greater damage each P/E cycle causes). The colder the nand, the longer the retention, but the slower the program and erase times are. NAND chips, by themselves, generally don't care power on or not. Devices they are put in care a great deal. Part of the garbage collection that's done by NAND devices ensures that the data is never put at undue risk. That's done by copying the active data out of blocks that are too old, or too hard to read. The details vary FTL to FTL, some will scan the device once in a while to make sure data can still be written, others do it mechanically with the passage of time. Data can be too hard to read if it is too old, or if it has been read too many times... Warner