Date: Sat, 21 Jan 2017 12:11:51 -0700 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org Subject: Re: how to measure microsd wear Message-ID: <1485025911.34897.199.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1485025911.34897.199.camel>