From owner-freebsd-arm@freebsd.org Sat Jan 21 19:11:54 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 75981CBB214 for ; Sat, 21 Jan 2017 19:11:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B2CF1E4A for ; Sat, 21 Jan 2017 19:11:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8950872a-e00d-11e6-8c89-112185c90658 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 8950872a-e00d-11e6-8c89-112185c90658; Sat, 21 Jan 2017 19:12:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v0LJBp10006941; Sat, 21 Jan 2017 12:11:51 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1485025911.34897.199.camel@freebsd.org> Subject: Re: how to measure microsd wear From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Sat, 21 Jan 2017 12:11:51 -0700 In-Reply-To: <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> References: <16821b7c-e300-97fc-36e5-a508b22c21b8@zyxst.net> <1485021485.34897.185.camel@freebsd.org> <1d757b3b-67d2-b29b-ba01-89b462b0019f@denninger.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Sat, 21 Jan 2017 19:11:54 -0000 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. -- 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. >