Live data from Hacker News

SDcard wear leveling and translation layers (2014)

msreekan.com

41–50 of 72 posts

Re: SDcard wear leveling and translation layers (2014)

#41
post #23

Earlier quoted context omitted.

Firmware definitely would not be on the filesystem layer or even accessible on the block device.

You'd think yeah

It isn't. Before a chip has firmware loaded, it can't decode filesystems.

Re: SDcard wear leveling and translation layers (2014)

#42
post #22

Why 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).

Are CFExpress cards similar/comparable at all to SD cards? Afaik CFExpress uses nvme, which will provide more features.

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)

#43

Earlier 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…

Losing the logs on a power outage may be a good compromise. Alternatively, you can buffer on a battery-powered RAM unit, accept that your cards will be short-lived, immediately send the logs through some network, not log...

When you are designing the hardware, you have lots and lots of choices.

Re: SDcard wear leveling and translation layers (2014)

#44

Earlier 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?

AFAIK, it's not clear how much difference in wear a series of writes cause when compared to writes and erases.

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)

#45

Earlier quoted context omitted.

You'd think yeah

It isn't. Before a chip has firmware loaded, it can't decode filesystems.

That doesn't at all mean that the firmware can't be exposed through the filesystem. Is that a bad idea? Almost certainly. Is it possible? Absolutely yes.

Re: SDcard wear leveling and translation layers (2014)

#46
post #29

Does 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

What is the point of charging for it, especially such an outrageous amount?

Re: SDcard wear leveling and translation layers (2014)

#47

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/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 more expensive, so I'm not sure how much different they could be ...

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)

#48

At 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…

Have an SD card that was copying file on to and in the middle of transfer the card went kaput and hasnt seen since. No machine I try it on even acknowledges it existence.

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)

#49

Earlier quoted context omitted.

You'd think yeah

It isn't. Before a chip has firmware loaded, it can't decode filesystems.

Even after a chip has firmware loaded, which controller can make logical sense of a filesystem?

Re: SDcard wear leveling and translation layers (2014)

#50
post #47

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/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…

Reliability is mostly just better software that does better write aggregation, wear levelling and error correction.

Develop it once, and you can make as many SD cards as you like reliable for no extra money...

Post reply on HN