Earlier quoted context omitted.
Firmware definitely would not be on the filesystem layer or even accessible on the block device.
You'd think yeah
SDcard wear leveling and translation layers (2014)
41–50 of 72 posts
Re: SDcard wear leveling and translation layers (2014)
#42Why there's not generalized discard/trim capabilities on USB/SD devices? It should be "easy" to agree some standard on that.
Even more strangely, proprietary SxS/XQD cards also don't support discard/trim, neither for devices nor from a PC. Only the more recent CFX cards support trim (most of them, but not with every reader, and formatting in a camera doesn't seem to issue them, perhaps to aid with data recovery in case of accidental formats).
Also, interesting thing one can do if you have a need for a CFExpress card (like a camera) and want to save some money. You can buy an adapter online such as the linked one, and then buy an m2.2230 ssd and put it in there. That’s how I made myself a cheaper 1TB CFExpress B card for my camera, and it’s doing just fine, even with 8k30fps at ~3.5Gb/s.
https://www.bhphotovideo.com/c/product/1685487-REG/monster_a...
Re: SDcard wear leveling and translation layers (2014)
#43Earlier quoted context omitted.
Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data. Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.
That could explain why my dashcam is working fine after ten years whereas my previous job's IoT devices regularly ate SD cards. (Then again, the IoT devices were also overheating badly whereas the dashcam was designed for its purpose, kept cool while running, and runs on a low duty cycle) What are you supposed to do, then? Buffer up writes and accept that you'll lose logs a minute or so before a power outage? As much…
When you are designing the hardware, you have lots and lots of choices.
Re: SDcard wear leveling and translation layers (2014)
#44Earlier quoted context omitted.
Pages that are already written cannot be overwritten, at least not without a full block erase, so it has to do a remap to append data. Directly logging to an SD card (i.e. lots of small writes) is the fastest way to destroy it.
As I understand it, you need a block erase to change bits from 0 to 1 then you can selectively set bits back from 1 to 0. Couldn't you perform a file append without the need for a block erase? By keeping the unwritten area as all ones until written?
I do know that very old flash firmwares applied that idea, and that new flash evolved in a direction where the wear caused by an erase is closer to the one caused by a write. If modern firmwares do not use it, it's probably because there isn't a lot to gain.
Re: SDcard wear leveling and translation layers (2014)
#45Re: SDcard wear leveling and translation layers (2014)
#46Does anyone have access to the full specs of some SD cards? To get access to the full specifications it seems like you're forced to join the SD Association: 2500$ p/year
Re: SDcard wear leveling and translation layers (2014)
#47I 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,…
You can get Swissbit pSLC (pseudo-SLC) SD cards from component distributers like Mouser and Digikey, and they are much more expensive, but should be "industrial grade". I've recently purchased a couple of their 8GB microsd cards for about $30 each (but haven't put them through a lot of real usage yet ...)
Re: SDcard wear leveling and translation layers (2014)
#48At 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…
The card is almost a decade old at this point but is there a way to recover data ?
Re: SDcard wear leveling and translation layers (2014)
#49Re: SDcard wear leveling and translation layers (2014)
#50I 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,…
SD Cards are just so damn cheap. Less than $20 USD for a 128GB microsd is unbelievable (cost and size). Only the most premium of the premium have a chance of surviving significant random or small writes, it seems. "Ultra" isn't quite enough, we need "Extreme Pro"? (Needing to figure out the ranking of superlatives is silly.) There's "Max Endurance" or "Pro Endurance" now, sounds promising ... but those are barely any…
Develop it once, and you can make as many SD cards as you like reliable for no extra money...