SD life expectancy

StevenR

Anyone have any real life experience on how many read/write cycles an SD can do.

I have a prop app that stores a MIDI file on an SD card in 512 byte block writes and then plays it. It reads and parses the file one byte at a time.

A MIDI file averages 30K in size so that means 30K reads just to play one file.

At that rate how long can I expect an SD to live?

Steven.

Jim Fouch

As far as I know reads do not count as a wear actavity like writes do. Most SD cards have wear leveling in their firmware and will move writes to different sectors to level the number of writes across the whole media. I would guess you would eventually wear out an SD card, but it would take billions of writes.

Duane C. Johnson

I have investigated this a bit.
My understanding is the writing lifetime is 5 to 10 thousand cycles.
But just as Jim said the hardware attempts to write to different sectors essentially using the whole before starting over again.

I have tried to abuse a card by writing a 100K byte file at least 2 million times. It never failed.
OK, this was well in excess of my needs so I quit.

Duane

Tor

It's more like 100000 cycles, not just 5-10000. Anyway none of my SD cards have failed yet, some are around 7 years old and being used all the time. I have not done anything like continuous writes on them, just normal usage.
It's probably not a good idea to write one byte at the time though.. it'll have to rewrite a full 32 bytes (if SD) or 512 bytes (if SDHC) every time. Depending a bit on the filesystem, the OS (if any), and the card itself - new, big cards keep some RAM write cache on board, so it can be a little difficult to figure out exactly what will happen if you write just one byte at the time. It's best to be a bit careful with it though.

-Tor

prof_braino

The only dead SD card I saw was a an early 4gig SDHC that possibly a defective run. All the rest are still working, even the old sub 1 Gig cards.

Paul Baker

Unless you are looking to rewriting to the same SD block every minute (or less), you do not need to worry about how long the card will last. Modern FLASH memory is rated at 100k-1M rewrites per cell, but this is MTBF not a hard number. Also some companies have wear leveling techniques for the cards (swap out blocks and block rotation) which effectively multiple the observed MTBF because the card will spread the writes over many blocks (while appearing to write to the same block) and replace a defective block when one fails.

Tracy Allen

Be aware also that there are different grades of cards. Consumer cards are mostly MLC (Multi Level Cell) technology. Each transistor stores two bits as 4 possible levels on its floating gate, and by that means achieves higher density but lower margins of error. Industrial cards on the other hand mostly use SLC (Single Level Cell) technology where each transistor stores one bit as two levels on the floating gate (Transcend example). There are also differences in the wear leveling and error correction codes implemented by the industrial cards. They are rated for wider temperature range and ostensibly better stability and longer life. There has to be some advantage to justify the price premium, 5 to 10x over the price of a commercial card. That said, I would usually balk at the price unless the system is going into a really critical location. As others have said, it is writing that is the main wear factor, and reading is less an issue, unless the cells "leak" over time, more likely at high temperatures. The build-in error correcting codes address all error sources.

LoopyByteloose

Tracy Allen points the way - you really get what you pay for in either SDcards or USB memory sticks.

While I have yet to wear out any of my SDcards, I skimped on a few USB memory sticks and all of those failed very early on. One was a free give-away from "The Economist" magazine.

I doubt if anyone will ever really know the useful life of these kinds of storage. I followed a huge debate with the EEEpc's solid state RAM and while it did offer solid strategies for wear reduction, nobody could pin down the useful life.

The fact that READS do not enter into the wear factor is very useful.

pedward

I just thought I'd chime in on a point here. Unix type operating systems maintain something called ATIME, or access time, for each file/directory. This is almost only used for biff to know if you've read your mail, since the MTIME and ATIME would be different. This is a source of a lot of useless I/O on Unix type operating systems, which translates into useless writes to storage media. This has a big impact on performance, and longevity if talking flash. I always disable ATIME housekeeping on my machines.

While not relevant to the Propeller directly, it is relevant to particular storage strategies.

LoopyByteloose

Yes indeed, both Linux and Unix will track and revise times for each file on a per view basis IF allowed to do so. That is not a good practice with SDcards or and other solid state storage. And it is easily turned off. SDcard inherently do not have this feature if formated in FAT32

This brings to mind another feature of Unix/Linux that is extremely handy ==> Read Only Partitions

After developing an application for a Propeller, it would be nice to have the whatever doesn't require revision located in a Read Only Partition. But the problem here is that SDcards and USB memory sticks are only optimized for MS files systems. You can format to a Linux EXT2 partition, but I suspect the wear-leveling features are no longer operating properly. At least you can have Read-Only Files.

Heater.

Loopy,

You can format to a Linux EXT2 partition, but I suspect the wear-leveling features are no longer operating properly.

Why would you suspect so?

Whatever operating system or file system you are using it ends up reading and writing blocks to wherever it likes on the SD.
The SD card has no idea what file system you are using.

I am currently using ARM boards running Linux that have a small FAT and a large EXT3 partition. No problem.

pedward

Hmm, an EXT2 filesystem object for Propeller....