From owner-freebsd-arm@freebsd.org Sun Jan 22 03:32:40 2017 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 4A746CAE80B for ; Sun, 22 Jan 2017 03:32:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 131F5DC for ; Sun, 22 Jan 2017 03:32:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x229.google.com with SMTP id l66so88767288ioi.1 for ; Sat, 21 Jan 2017 19:32:40 -0800 (PST) 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:from:date:message-id :subject:to:cc; bh=8Jkgw5WLh18r7ET7E3VAd2ar4MGpZw7d3bJh6yS7BHQ=; b=EebyWo3W45p+jFIHUcfTMrsWAz9thTtS186hYOwnKZXMGjph6AiAWrg2ULsCRn8UDx sN4Gdt4rTyvWkSAdr16DMtvaiekS5CO6+XUq82vR/7vJQbgdM1JEZQg+x9qJiBYeP2tH MxKltwfIEeYvYF/BMPYmP950RnBB0R4L98SCsPiH9roExm5byNDMT7FE9QCPw8AV10Yn X+moOG34ApA88ODr0RneCRnq6t0j1TK4E6s2YIjrXXqDc539GQGDeweLjzQ13WGWxOku rqvNPFA+DS+uOoLU0g1izNrvPaYVfx9yuQyhlDaWpPzXryQ8tbpxM+G9EXWvxboyp1zV 8wrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8Jkgw5WLh18r7ET7E3VAd2ar4MGpZw7d3bJh6yS7BHQ=; b=ecnakFGtf7vXqeUzek3Di7le15mcRJGh+E3v6G5LnEMUoHR4obIYqqpbHodAwH3hZW N+mISpgL9EsWxPfq0IHH+wXuVvgojuHCIMXPSVmi80JtEMqfK8b4Td71C+5X2WNGU0vG +XyWNN5QW0uvt7Vv83/gvatdkIppnur6qPGBj2PNw36nfY3fT38uybmSFsfheUydXuWU cu4HEehUas7tWsDCvFuUZK2UPziMiAQspOJpX7zMSAiySTW/pn+QytJL3W6g7BBqd//U jaU+2dBXikiokgaWbimQuyRGpH/nez5mZ3Dd/5RnWfxsIoPvpmU6Vc/NTXDCInu8YZUh oDAg== X-Gm-Message-State: AIkVDXLdpK/UViDrUIAk56WXlsL2+0i/PhK2k13a6E7/X13NMvIDfclHoT8qe3Ngy7pKESYwrFePCG4fUb/bVw== X-Received: by 10.107.139.131 with SMTP id n125mr21294482iod.166.1485055959016; Sat, 21 Jan 2017 19:32:39 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.145.217 with HTTP; Sat, 21 Jan 2017 19:32:38 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <1485025911.34897.199.camel@freebsd.org> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> <1485025911.34897.199.camel@freebsd.org> From: Warner Losh Date: Sat, 21 Jan 2017 20:32:38 -0700 X-Google-Sender-Auth: BRFjIRjVMjQ_iVBdlAxXoGn2Mlw Message-ID: Subject: Re: how to measure microsd wear To: Ian Lepore Cc: Karl Denninger , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 03:32:40 -0000 On Sat, Jan 21, 2017 at 12:11 PM, Ian Lepore wrote: > On Sat, 2017-01-21 at 12:12 -0600, Karl Denninger wrote: >> On 1/21/2017 11:58, Ian Lepore wrote: >> > >> > On Sat, 2017-01-21 at 15:46 +0000, tech-lists wrote: >> > > >> > > Hello list, >> > > >> > > How would one measure microsd wear? Is there a utility like >> > > smartmontools (I think this only works for regular hard drives) >> > > but >> > > for >> > > microsd? >> > > >> > > many thanks, >> > There is basically no way to see what's going on in the flash array >> > of >> > an sdcard. The microcontrollers in modern sd cards have complex >> > wear- >> > leveling algorithms which are completely transparent to the outside >> > world. >> This is true. >> > >> > On the plus side, most of what you see in the way of warnings and >> > scare >> > stories about wearing out sd cards is pure BS. I've got systems >> > here >> > that have been running for literally years on the same sdcard, and >> > that >> > card is being used for swap, and routine data storage like syslog >> > (on >> > an embedded system that logs status and progress pretty much >> > continuously 24x7 for years). I've seen a few sd cards die over >> > the >> > years, but I've never been able to say it was because of how much >> > was >> > written to them (indeed, the dead ones I've got weren't in service >> > long >> > before they died). >> > >> This, however, is total nonsense. >> > > Well, no, it's not total nonsense, it's my 10 years of experience > professionally working with sd cards in embedded systems sold as > commericial products, including extensive testing of the card trying to > *induce* failure. > > Next time think twice before implying I'm either a fool or a liar. > > I'm not even going to read the rest of the crap you wrote, since it's > completely invalidated by the stupid thing you said above. Yea. I've killed enough SD cards to say that extra writes are an issue. I've personally written flash reliability systems. I can tell you that saying "all SD cards do" is automatically wrong. Some SD cards are awesome: they are fast, reliable and rarely brake. Others are slow, unreliable and crap. Utter crap. Not worth the time it takes to order them. It all has to do with the type of NAND that's in the card. Some of it has been SLC which you can write 20k times without even breaking a sweat. Others is TLC which is doing good for 100-200 writes. There's a huge difference between these two polar extremes. On the latter it is super critical that one writes as little as possible because a 32GB card may only have 3.2TB written before they are in the danger zone, which is super easy to do. So maybe some people get lucky and don't have problems. I've never blinded myself by staring at the sun, but that sure doesn't make it a safe thing to do. Warner > > -- Ian > > >> I've had multiple SD card failures in build/test/high-volume write >> environments on the PI2 series over the last year and change. There >> are >> two general ways in which you will see failures: >> >> 1. The card write-locks itself. This is a defensive move by the >> controller when it determines that it cannot reallocate a failed >> block >> during a write (e.g. it's out of spares) OR it takes an unrecoverable >> read error. >> >> 2. The card loses its allocation map (in which case you're completely >> screwed; it will show up as zero size if you manage to get it mounted >> somewhere.) >> >> If you get a type 1 failure you can copy everything on the card off; >> provided you do not attempt to write it, you will not get >> errors. Prior >> to a fairly recent MFC if you had soft-updates on and took a Type 1 >> failure you'd get an instant panic; this has been (I believe >> entirely) >> fixed. >> >> In the event you get a Type 2 failure there's nothing you can do. In >> both cases the card is junk if it happens. >> > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"