SDcard wear leveling and translation layers (2014)

At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out <i>why</i> they broke.<p>One of the anecdotes I distinctly recall was about a batch of cards that (for obvious cost saving reasons) used the actual data flash to store its own firmware as well.<p>IIRC due to a bug in the wear leveling accounting, once the card got sufficiently full, the wear leveling code ended up partially overwriting the firmware itself.

Does anyone have access to the full specs of some SD cards? To get access to the full specifications it seems like you&#x27;re forced to join the SD Association: 2500$ p&#x2F;year

Why there&#x27;s not generalized discard&#x2F;trim capabilities on USB&#x2F;SD devices? It should be &quot;easy&quot; to agree some standard on that.

<i>&gt; For example, lets consider that we wrote to the sector 1024 on the SDCARD, and this address got initially mapped to physical sector 1024 itself on flash. Later we overwrite the contents, but this time write cannot go to the same physical address because it needs to be erased before programmed again.</i><p>Maybe someone here will know the answer to something I&#x27;ve been wondering for a while: When appending to a file with writes smaller than a sector, does this remapping process trigger every time? Or is the controller smart enough that it can append without remapping, even though to overwrite would need remapping?<p>Obviously for an SD card used for saving photos or videos you could write a sector at a time - but for an SD card in a temperature logger or similar, your appends might be a lot smaller.

I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read&#x2F;write errors.<p>I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller.<p>For compatibility with existing OS&#x27;s, that would take the form of a self-partition-resizing sd card. It would understand fat32, ext3, NTFS, afs etc, and when the card is next powered up the partition would be slightly smaller and files physically at the &#x27;end&#x27; would be moved inwards.<p>For newer OS&#x27;s, a new API could be introduced which tells the OS &#x27;this card is smaller now, please give me some blocks to mark as unavailable&#x27;.<p>The now-smaller card can use the removed-and-worn-out blocks to store error correction data for the remaining blocks. Ie. Additional error correction data on top of the data already stored within each page.<p>That effectively dramatically increases the lifespan of each page, at the cost of reduced IO performance.