[lug] USB "wear out" was: dd ssh pipe to bzip?

[Stephen Queen]

> Is it an urban myth that flash media will "wear out"?  I remember
> hearing back in the day that USB sticks have limited write cycles, but
> lately I've seen things that indicate those cycles are approximately
> the same as the number of cycles you get on a hard drive platter.  In
> other words, there's no longer any real difference between writes on
> USB and HDD.
>
> In addition, the number of writes is some huge number per cell and it's
> unlikely you'd ever hit that unless you specifically had a program
> constantly writing to exactly the same location on the drive...
>
> Any insight?
>

>This scrolled across reddit just the other day:

>
http://www.bress.net/blog/archives/114-How-Long-Does-a-Flash-Drive-Last.html

I work with a data logging system that uses USB sticks for data storage. We
bought a good quality stick.
http://www.corsair.com/products/survivor/default.aspx

At the end of each day a field hand goes to each logger (approx. 20 to 40)
and collects the sticks for that day.
We painted the ends of each stick with one of two colors. Each day we change
colors from the day before. So
we have orange days, and we have yellow days.

This is a new system so we haven't quantified the failure rate very well
yet, but it seems that the USB sticks fail
after about 50 to 100 days of use.

In all fairness, they are mishandled badly. The field hands don't use the
covers that are provided with them, and
they tend to stick them in their pockets as they collect them and distribute
them. I have speculated that it is the
connector failing, or static damage caused by shoving them into pockets. At
this time it appears to be the stick
and not the receiving connector that fails. That could be because of dirt
that is in the pockets of the field hands.

I am reasonably certain that the failures are not because of the number of
read/write cycles.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20101118/390a36fa/attachment.html>