how to measure microsd wear

[Warner Losh]

On Sat, Jan 21, 2017 at 12:11 PM, Ian Lepore <ian at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"