# How do they execute wear leveling systems in Flash cards?

**URL:** <https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256>\
**Category:** Factual Questions\
**Created:** [October 20, 2006, 5:51pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256 "2006-10-20T17:51:13Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Napier](https://avatars.discourse-cdn.com/v4/letter/n/ce73a5/32.png) [@Napier](https://boards.straightdope.com/u/Napier)\
**Post date:** [October 20, 2006, 5:51pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/1 "2006-10-20T17:51:13Z")

</div>

Flash cards can only handle 100,000 or so writes to a given address, but are divided into sectors that are used according to an internal wear leveling system so that all sectors age similarly on average.

How does this system work, if it can’t keep rewriting its own records in the same place? Doesn’t the card need a little space with a much longer service life in which to do the recordkeeping required to do the load leveling for the rest of the space?

---

<div class="post-metadata">

**Author:** ![astro](https://avatars.discourse-cdn.com/v4/letter/a/9dc877/32.png) [@astro](https://boards.straightdope.com/u/astro)\
**Post date:** [October 20, 2006, 6:17pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/2 "2006-10-20T18:17:09Z")

</div>

[QUOTE=Napier]  
Flash cards can only handle 100,000 or so writes to a given address, but are divided into sectors that are used according to an internal wear leveling system so that all sectors age similarly on average.

How does this system work, if it can’t keep rewriting its own records in the same place? Doesn’t the card need a little space with a much longer service life in which to do the recordkeeping required to do the load leveling for the rest of the space?  
[/QUOTE]

No idea but given the relatively few number of times in real life that a flash card is actually write to vs it’s theoretical limits, I’d guess that the few cards they replace due to this limit being exceeded (and beyond that this being the diagnosed problem) is infinitesimally small. I don’t tthink it would make economic sense to engineer in special protections for this wear issue beyond some sort of read-write distribution algorithm.

---

<div class="post-metadata">

**Author:** ![Gus\_Gusterson](https://avatars.discourse-cdn.com/v4/letter/g/85f322/32.png) [@Gus\_Gusterson](https://boards.straightdope.com/u/Gus_Gusterson)\
**Post date:** [October 20, 2006, 6:25pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/3 "2006-10-20T18:25:39Z")

</div>

The algorithms are proprietary. I doubt any of them are described completely in any resource accessible online.

Whatever state information it needs to retain can also be moved around the card to avoid writing to the same area too much.

---

<div class="post-metadata">

**Author:** ![iamthewalrus\_3](https://avatars.discourse-cdn.com/v4/letter/i/258eb7/32.png) [@iamthewalrus\_3](https://boards.straightdope.com/u/iamthewalrus_3)\
**Post date:** [October 20, 2006, 6:45pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/4 "2006-10-20T18:45:19Z")

</div>

[QUOTE=Gus Gusterson]  
Whatever state information it needs to retain can also be moved around the card to avoid writing to the same area too much.  
[/QUOTE]  
I think that’s sort of the OP’s point. If the file table (or whatever) is constantly moved around the card, how do you know where to look for it? There has to be _something_ that’s in an easily predictable place that will tell you where to look for more information. And every time you move the file table (or whatever), you’ll have to rewrite that first bootstrapping pointer. Which means that that address will get rewritten all the time.

I’m not sure what they actually do, but I have a few ideas.

The most obvious one is that that basic filesystem pointer isn’t kept on the rewritable flash itself while running, but in some volatile memory format. That way you reduce the number of rewrites to once per reset/power cycle. 100,000 writes is pretty conservative for flash; lots of flash chips are specced at orders of magnitudes more. And other stuff will wear out long before you can put a device through 100,000 power cycles. That way, you can rewrite the file table with each write, and just keep track of where the most recent write was. You’d still have to have some way of recovering the filesystem in case of a catastrophic loss, but either a journaling system, or some known way of crawling the filesystem for the most recent data would do fine.

---

<div class="post-metadata">

**Author:** ![gazpacho](https://avatars.discourse-cdn.com/v4/letter/g/6f9a4e/32.png) [@gazpacho](https://boards.straightdope.com/u/gazpacho)\
**Post date:** [October 20, 2006, 6:47pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/5 "2006-10-20T18:47:29Z")

</div>

Just off the top of my head I can think of a few ways to do it. But if you really care search with the google scholar [http://scholar.google.com/](http://scholar.google.com/) search and pull up papers on this.

> **[Algorithms and data structures for flash memories | ACM Computing Surveys](https://dl.acm.org/doi/10.1145/1089733.1089735)**
>
> Flash memory is a type of electrically-erasable programmable read-only memory (EEPROM).
> Because flash memories are nonvolatile and relatively dense, they are now used to
> store files and other persistent objects in handheld computers, mobile phones,...

Looks like it may survey a few techniques.

Here is one way.  
In general flash is erased in blocks of say 1 kbyte and then writen in smaller chunks 8 to 32 bits. In say the first block you could have a pointer to the leveling information. When the information is updated you write the pointer in the next address. When looking up the address of the leveling information you use the information in the last non blank entry in the first block. Now the first block needs to be erased only once every few hundred writes.

---

<div class="post-metadata">

**Author:** ![astro](https://avatars.discourse-cdn.com/v4/letter/a/9dc877/32.png) [@astro](https://boards.straightdope.com/u/astro)\
**Post date:** [October 20, 2006, 6:56pm UTC](https://boards.straightdope.com/t/how-do-they-execute-wear-leveling-systems-in-flash-cards/377256/6 "2006-10-20T18:56:47Z")

</div>

[Wiki on wear leveling](http://en.wikipedia.org/wiki/Wear_levelling)

[Sandisk white paper on wear leveling](http://www.sandisk.com/Assets/File/OEM/WhitePapersAndBrochures/RS-MMC/WPaperWearLevelv1.0.pdf)

[Dynamic & static wear leveling](http://www.m-sys.com/NR/rdonlyres/FCC7D817-38A5-4D80-8471-67DA793EA255/0/TN_017_TrueFFS_Wear_Leveling_Mechanism.pdf%7CTN_017_TrueFFS_Wear_Leveling_Mechanism.pdf)

[Lots here on flash algorithms & data structures at $ 10 a pop](http://portal.acm.org/dl.cfm?coll=portal&dl=ACM&CFID=2685595&CFTOKEN=25929582)
