SDcard wear leveling and translation layers (2014)
1–10 of 72 posts
Re: SDcard wear leveling and translation layers (2014)
#2[deleted]
Re: SDcard wear leveling and translation layers (2014)
#3[deleted]
Re: SDcard wear leveling and translation layers (2014)
#4At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out why they broke.
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.
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.
Re: SDcard wear leveling and translation layers (2014)
#5At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out why they broke. 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. IIRC due to a bug in the wear leveling accounting, once the card got sufficiently full, the wear leveling code ended up…
I recall once having an SD card with a mysterious file in the root folder with system and hidden attributes on it. I decided to delete the file and some time later (months), the card suddenly stopped working.
It maybe stopped working once the OS decided the bytes were available for use (which it would only have done without the file marking that space as unavailable) and overwrote that section. I suspect defragmenting or otherwise moving the file about for whatever reason would have had the same effect.
Re: SDcard wear leveling and translation layers (2014)
#6At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out why they broke. 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. IIRC due to a bug in the wear leveling accounting, once the card got sufficiently full, the wear leveling code ended up…
I recall once having an SD card with a mysterious file in the root folder with system and hidden attributes on it. I decided to delete the file and some time later (months), the card suddenly stopped working. It maybe stopped working once the OS decided the bytes were available for use (which it would only have done without the file marking that space as unavailable) and overwrote that section. I suspect defragmentin…
Wouldn't a regular filesystem format of the card have the same effect - wipe the file? Wouldn't such SD cards be fatally flawed for most applications? My camera, drone, etc. all format the cards.
Re: SDcard wear leveling and translation layers (2014)
#7At a conference, I once met somebody who said his team had the joy of dismantling broken SD cards and figuring out why they broke. 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. IIRC due to a bug in the wear leveling accounting, once the card got sufficiently full, the wear leveling code ended up…
Man, I'd love to work in that team for a year. I've had so many SD cards fail on me (most recently a 1TB SanDisk Extreme which was used in my Steam Deck) and it feels like most of them are junk.
Re: SDcard wear leveling and translation layers (2014)
#8Earlier quoted context omitted.
I recall once having an SD card with a mysterious file in the root folder with system and hidden attributes on it. I decided to delete the file and some time later (months), the card suddenly stopped working. It maybe stopped working once the OS decided the bytes were available for use (which it would only have done without the file marking that space as unavailable) and overwrote that section. I suspect defragmentin…
Wouldn't a regular filesystem format of the card have the same effect - wipe the file? Wouldn't such SD cards be fatally flawed for most applications? My camera, drone, etc. all format the cards.
I vaguely recall thinking the file was just some sort of serial number or stock tracking metadata when I deleted it. It might have instead failed for quite mundane reasons such as low quality manufacture. I don't know.
Exposing the firmware in this fashion would be a bad idea for all of these reasons. It is a good thing that SD card manufacturers don't do this any more, if they ever did.
Re: SDcard wear leveling and translation layers (2014)
#9I am really disappointed by SD card reliability. It seems even a little wear and the whole thing slows down massively and eventually throws read/write errors.
I would like to see a card design which, instead of failing when there is flash wear, instead just gets smaller.
For compatibility with existing OS'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 'end' would be moved inwards.
For newer OS's, a new API could be introduced which tells the OS 'this card is smaller now, please give me some blocks to mark as unavailable'.
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.
That effectively dramatically increases the lifespan of each page, at the cost of reduced IO performance.
Re: SDcard wear leveling and translation layers (2014)
#10> 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.
Maybe someone here will know the answer to something I'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?
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.