Date: Sat, 21 Jan 2017 20:32:38 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@freebsd.org> Cc: Karl Denninger <karl@denninger.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: how to measure microsd wear Message-ID: <CANCZdfqrMu3=B-LVaD58O=bybtz=hiWb4vUC%2BwC2MttS%2B%2BibOQ@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jan 21, 2017 at 12:11 PM, Ian Lepore <ian@freebsd.org> 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqrMu3=B-LVaD58O=bybtz=hiWb4vUC%2BwC2MttS%2B%2BibOQ>